------=_Part_1643_829318647.1449201166354
Content-Type: multipart/alternative;
 boundary="----=_Part_1644_1840081950.1449201166355"

------=_Part_1644_1840081950.1449201166355
Content-Type: text/plain; charset=UTF-8

I am seriously against P0145R0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf>. As a
user of C++, I urge EWG and CWG to reconsider the reasons to adopt this
proposal.

To be systemic, here are my reasons:

   1. It is a breaking change.
   2. It complicates the language itself. (If in doubt, compare the
   wording, please.)
   3. As mentioned above, it may harm to optimization.
   4. The reason represented by the proposal is unsound. It harms
   teachability and makes it hard to get consensus on conventional ("best")
   practice.

I feels the first 2 points should be acknowledged here.

To the 3rd point, one key point I'd note here is: *this change forbids a
portable way to easily express the unsequenced evaluation of an expression* *intended
*by the author of the code.

For this purpose, I currently explicitly used the unsequenced function
parameter rule
<https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=master&fileviewer=file-view-default#ydef.h-938>
and a macro wrapper
<https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=master&fileviewer=file-view-default#ydef.h-956>
for readability. (It would probably be better with PR0146R0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html>.)
However, the change by this proposal makes it a joke.

Specifically, I can, but don't want to:

// Not portable!
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-std=c++11" // Huh, is it documented?
// ...
#pragma GCC diagnostic pop

For the 4th point, one key point is: *it is nonsense to support bad code*.

If the author want the clear evaluation order, do extract the subexpression
as a single statement (followed by ';'). This transformation should not be
a problem on well-formed code since even constexpr functions now support
multiple statements in the body, and there are lambdas.

What if the author do not know what order they want ... who allow they to
code such spaghetti?

I don't think anyone should be encourage to write such code except for the
purpose of testing the implementation (e.g. [-Wsequenced] or ubsan). Any
senior C++ user would probable agree this point easily by their experience.
The code should be reject by the contemporary style because it causes
confusion. The suggestion of change itself also has caused such problem,
see comments on Herb Sutter's poll
<http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation>.

To reduce the potential risks, a programmer who don't have enough common
sense about sequence rules (also imply the definition of "undefined
behavior"), should not be granted permission of modify the C++ code base in
a serious project. This is similar to C which uses similar UB rules with
"sequence point" wording. *These knowledge should be at very basic level of
the language.* The unsequenced evaluation rules are excellent examples
about the position and importance of these rules. Other subtle rules are
usually more difficult to learn. That's why I think the change harms the
teachability: we'd lost a chance to tell the newbies to discipline
themselves about being responsible to what they'd write, which is hard to
rescue later. This is super important for a language has so many traps to
use.

There are more details about the rules, e.g. I think CWG222
<http://wg21.cmeerw.net/cwg/issue222>is a good change. It also loose the
requirements on user code, but it does not have the drawbacks above, esp.
it did not introduce the confusions like above.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I am seriously against <a href=3D"http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf">P0145R0</a>. As a user of C++,=
 I urge EWG and CWG to reconsider the reasons to adopt this proposal.<br><b=
r>To be systemic, here are my reasons:<br><ol><li>It is a breaking change.<=
/li><li>It complicates the language itself. (If in doubt, compare the wordi=
ng, please.)</li><li>As mentioned above, it may harm to optimization.</li><=
li>The reason represented by the proposal is unsound. It harms teachability=
 and makes it hard to get consensus on conventional (&quot;best&quot;) prac=
tice.<br></li></ol>I feels the first 2 points should be acknowledged here.<=
br><br>To the 3rd point, one key point I&#39;d note here is: <b>this change=
 forbids a portable way to easily express the unsequenced evaluation of an =
expression</b> <i>intended </i>by the author of the code.<br><br>For this p=
urpose, I currently explicitly <a href=3D"https://bitbucket.org/FrankHB/ysl=
ib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=3Dm=
aster&amp;fileviewer=3Dfile-view-default#ydef.h-938">used the unsequenced f=
unction parameter rule</a> and <a href=3D"https://bitbucket.org/FrankHB/ysl=
ib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=3Dm=
aster&amp;fileviewer=3Dfile-view-default#ydef.h-956">a macro wrapper</a> fo=
r readability. (It would probably be better with <a href=3D"http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html">PR0146R0</a>.) Howev=
er, the change by this proposal makes it a joke.<br><br>Specifically, I can=
, but don&#39;t want to:<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"=
styled-by-prettify"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #800;" class=3D"styled-by-prettify">// Not portabl=
e!<br>#pragma</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> GCC diagnostic push<br></span></div></code>#pragma</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> GCC diagnostic warning </span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify">&quot;-std=3Dc++1=
1&quot;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Huh, is i=
t documented?<br>// ...</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">#pragma</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> GCC diagnostic pop<br></span></div></code></div><br>For the 4th point,=
 one key point is: <b>it is nonsense to support bad code</b>.<br><br>If the=
 author want the clear evaluation order, do extract the subexpression as a =
single statement (followed by &#39;;&#39;). This transformation should not =
be a problem on well-formed code since even constexpr functions now support=
 multiple statements in the body, and there are lambdas.<br><br>What if the=
 author do not know what order they want ... who allow they to code such sp=
aghetti?<br><br>I don&#39;t think anyone should be encourage to write such =
code except for the purpose of testing the implementation (e.g. [-Wsequence=
d] or ubsan). Any senior C++ user would probable agree this point easily by=
 their experience. The code should be reject by the contemporary style beca=
use it causes confusion.
 The suggestion of change itself also has caused such problem, see=20
comments on <a href=3D"http://herbsutter.com/2014/12/01/a-quick-poll-about-=
order-of-evaluation">Herb Sutter&#39;s poll</a>.<br><br>To reduce the poten=
tial risks, a programmer who don&#39;t have enough common sense about seque=
nce rules (also imply the definition of &quot;undefined behavior&quot;), sh=
ould not be granted permission of modify the C++ code base in a serious pro=
ject. This is similar to C which uses similar UB rules with &quot;sequence =
point&quot; wording. <b>These knowledge should be at very basic level of th=
e language.</b> The unsequenced evaluation rules are excellent examples abo=
ut the position and importance of these rules. Other subtle rules are usual=
ly more difficult to learn. That&#39;s why I think the change harms the tea=
chability: we&#39;d lost a chance to tell the newbies to discipline themsel=
ves about being responsible to what they&#39;d write, which is hard to resc=
ue later. This is super important for a language has so many traps to use.<=
br><br>There are more details about the rules, e.g. I think <a href=3D"http=
://wg21.cmeerw.net/cwg/issue222">CWG222 </a>is a good change. It also loose=
 the requirements on user code, but it does not have the drawbacks above, e=
sp. it did not introduce the confusions like above.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1644_1840081950.1449201166355--
------=_Part_1643_829318647.1449201166354--

.

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

P0145R0 is bad for two reasons.  First, it (deliberately) does not specify
a fixed order of evaluation for all expressions (thereby failing to solve
the problem it ostensibly addresses), and second, it does not specify that
the order should always be strictly left-to-right (thereby failing to
provide a rule which is simple to understand).  (Point 2 above is thus a
consequence.)

Point 1 above is wrong.  A change that specifies behavior formerly
unspecified cannot be breaking.  Implementations that have made promises
beyond what the standard offers can be broken, but that is not the problem
of the committee.  Programmers who relied on their implementation's order
are, as per Point 4 above, to be scorned.

Point 4 above places the cart squarely in front of the horse.  The reason
programmers have so much trouble with the existing rules is that the
existing rules are stupid.  The way to fix the situation is to fix the
stupid rules, not to treat them as a *pons asinorum* so that smug
superiority can be asserted.  The code would not be bad if the language had
correct rules.

Point 4 prime, that programmers wish to indicate that they do not care
about order, is, to continue the animal metaphors, a red herring.  How, for
example, given two functions void f(); and void g();, how would you
indicate that you want them called unsequenced?

That leaves optimization.  In the old days, when parameters were passed on
the stack, left-to-right evaluation might have led to some pessimization.
But modern architectures pass arguments in registers, so that no longer
matters.  Nevertheless, I do expect the proponents of the status quo to
start pulling out examples where some compiler produces worse code, because
that's what they always do - this argument has been going on for decades.
The Max Planck paraphrase that "science progresses one funeral at a time"
has never been more true.

On Thu, Dec 3, 2015 at 10:52 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:

> I am seriously against P0145R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf>. As
> a user of C++, I urge EWG and CWG to reconsider the reasons to adopt this
> proposal.
>
> To be systemic, here are my reasons:
>
>    1. It is a breaking change.
>    2. It complicates the language itself. (If in doubt, compare the
>    wording, please.)
>    3. As mentioned above, it may harm to optimization.
>    4. The reason represented by the proposal is unsound. It harms
>    teachability and makes it hard to get consensus on conventional ("best")
>    practice.
>
> I feels the first 2 points should be acknowledged here.
>
> To the 3rd point, one key point I'd note here is: *this change forbids a
> portable way to easily express the unsequenced evaluation of an expression* *intended
> *by the author of the code.
>
> For this purpose, I currently explicitly used the unsequenced function
> parameter rule
> <https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=master&fileviewer=file-view-default#ydef.h-938>
> and a macro wrapper
> <https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=master&fileviewer=file-view-default#ydef.h-956>
> for readability. (It would probably be better with PR0146R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html>.)
> However, the change by this proposal makes it a joke.
>
> Specifically, I can, but don't want to:
>
> // Not portable!
> #pragma GCC diagnostic push
> #pragma GCC diagnostic warning "-std=c++11" // Huh, is it documented?
> // ...
> #pragma GCC diagnostic pop
>
> For the 4th point, one key point is: *it is nonsense to support bad code*.
>
> If the author want the clear evaluation order, do extract the
> subexpression as a single statement (followed by ';'). This transformation
> should not be a problem on well-formed code since even constexpr functions
> now support multiple statements in the body, and there are lambdas.
>
> What if the author do not know what order they want ... who allow they to
> code such spaghetti?
>
> I don't think anyone should be encourage to write such code except for the
> purpose of testing the implementation (e.g. [-Wsequenced] or ubsan). Any
> senior C++ user would probable agree this point easily by their experience.
> The code should be reject by the contemporary style because it causes
> confusion. The suggestion of change itself also has caused such problem,
> see comments on Herb Sutter's poll
> <http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation>.
>
> To reduce the potential risks, a programmer who don't have enough common
> sense about sequence rules (also imply the definition of "undefined
> behavior"), should not be granted permission of modify the C++ code base in
> a serious project. This is similar to C which uses similar UB rules with
> "sequence point" wording. *These knowledge should be at very basic level
> of the language.* The unsequenced evaluation rules are excellent examples
> about the position and importance of these rules. Other subtle rules are
> usually more difficult to learn. That's why I think the change harms the
> teachability: we'd lost a chance to tell the newbies to discipline
> themselves about being responsible to what they'd write, which is hard to
> rescue later. This is super important for a language has so many traps to
> use.
>
> There are more details about the rules, e.g. I think CWG222
> <http://wg21.cmeerw.net/cwg/issue222>is a good change. It also loose the
> requirements on user code, but it does not have the drawbacks above, esp.
> it did not introduce the confusions like above.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">P0145R0 is bad for two reasons.=C2=A0 First, it (deliberat=
ely) does not specify a fixed order of evaluation for all expressions (ther=
eby failing to solve the problem it ostensibly addresses), and second, it d=
oes not specify that the order should always be strictly left-to-right (the=
reby failing to provide a rule which is simple to understand). =C2=A0(Point=
 2 above is thus a consequence.)<br><br>Point 1 above is wrong.=C2=A0 A cha=
nge that specifies behavior formerly unspecified cannot be breaking.=C2=A0 =
Implementations that have made promises beyond what the standard offers can=
 be broken, but that is not the problem of the committee.=C2=A0 Programmers=
 who relied on their implementation&#39;s order are, as per Point 4 above, =
to be scorned.<br><div><br></div><div>Point 4 above places the cart squarel=
y in front of the horse.=C2=A0 The reason programmers have so much trouble =
with the existing rules is that the existing rules are stupid.=C2=A0 The wa=
y to fix the situation is to fix the stupid rules, not to treat them as a <=
i>pons asinorum</i>=C2=A0so that smug superiority can be asserted.=C2=A0 Th=
e code would not be bad if the language had correct rules.<br><br>Point 4 p=
rime, that programmers wish to indicate that they do not care about order, =
is, to continue the animal metaphors, a red herring.=C2=A0 How, for example=
, given two functions <font face=3D"monospace, monospace">void f();</font> =
and <font face=3D"monospace, monospace">void g();</font>, how would you ind=
icate that you want them called unsequenced?<br><br>That leaves optimizatio=
n.=C2=A0 In the old days, when parameters were passed on the stack, left-to=
-right evaluation might have led to some pessimization.=C2=A0 But modern ar=
chitectures pass arguments in registers, so that no longer matters.=C2=A0 N=
evertheless, I do expect the proponents of the status quo to start pulling =
out examples where some compiler produces worse code, because that&#39;s wh=
at they always do - this argument has been going on for decades.=C2=A0 The =
Max Planck paraphrase that &quot;science progresses one funeral at a time&q=
uot; has never been more true.<br></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Thu, Dec 3, 2015 at 10:52 PM, FrankHB1989 <=
span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com" target=3D"_bl=
ank">frankhb1989@gmail.com</a>&gt;</span> wrote:<br><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">I am seriously against <a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf" target=3D"_blank">P014=
5R0</a>. As a user of C++, I urge EWG and CWG to reconsider the reasons to =
adopt this proposal.<br><br>To be systemic, here are my reasons:<br><ol><li=
>It is a breaking change.</li><li>It complicates the language itself. (If i=
n doubt, compare the wording, please.)</li><li>As mentioned above, it may h=
arm to optimization.</li><li>The reason represented by the proposal is unso=
und. It harms teachability and makes it hard to get consensus on convention=
al (&quot;best&quot;) practice.<br></li></ol>I feels the first 2 points sho=
uld be acknowledged here.<br><br>To the 3rd point, one key point I&#39;d no=
te here is: <b>this change forbids a portable way to easily express the uns=
equenced evaluation of an expression</b> <i>intended </i>by the author of t=
he code.<br><br>For this purpose, I currently explicitly <a href=3D"https:/=
/bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/Y=
Base/include/ydef.h?at=3Dmaster&amp;fileviewer=3Dfile-view-default#ydef.h-9=
38" target=3D"_blank">used the unsequenced function parameter rule</a> and =
<a href=3D"https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb6=
74020ae92fe2d256/YBase/include/ydef.h?at=3Dmaster&amp;fileviewer=3Dfile-vie=
w-default#ydef.h-956" target=3D"_blank">a macro wrapper</a> for readability=
.. (It would probably be better with <a href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2015/p0146r0.html" target=3D"_blank">PR0146R0</a>.) =
However, the change by this proposal makes it a joke.<br><br>Specifically, =
I can, but don&#39;t want to:<br><br><div 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:#800"><code><div><sp=
an style=3D"color:#800">// Not portable!<br>#pragma</span><span style=3D"co=
lor:#000"> GCC diagnostic push<br></span></div></code>#pragma</span><span s=
tyle=3D"color:#000"> GCC diagnostic warning </span><span style=3D"color:#08=
0">&quot;-std=3Dc++11&quot;</span><span style=3D"color:#000"> </span><span =
style=3D"color:#800">// Huh, is it documented?<br>// ...</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#800">#pragma</span><span s=
tyle=3D"color:#000"> GCC diagnostic pop<br></span></div></code></div><br>Fo=
r the 4th point, one key point is: <b>it is nonsense to support bad code</b=
>.<br><br>If the author want the clear evaluation order, do extract the sub=
expression as a single statement (followed by &#39;;&#39;). This transforma=
tion should not be a problem on well-formed code since even constexpr funct=
ions now support multiple statements in the body, and there are lambdas.<br=
><br>What if the author do not know what order they want ... who allow they=
 to code such spaghetti?<br><br>I don&#39;t think anyone should be encourag=
e to write such code except for the purpose of testing the implementation (=
e.g. [-Wsequenced] or ubsan). Any senior C++ user would probable agree this=
 point easily by their experience. The code should be reject by the contemp=
orary style because it causes confusion.
 The suggestion of change itself also has caused such problem, see=20
comments on <a href=3D"http://herbsutter.com/2014/12/01/a-quick-poll-about-=
order-of-evaluation" target=3D"_blank">Herb Sutter&#39;s poll</a>.<br><br>T=
o reduce the potential risks, a programmer who don&#39;t have enough common=
 sense about sequence rules (also imply the definition of &quot;undefined b=
ehavior&quot;), should not be granted permission of modify the C++ code bas=
e in a serious project. This is similar to C which uses similar UB rules wi=
th &quot;sequence point&quot; wording. <b>These knowledge should be at very=
 basic level of the language.</b> The unsequenced evaluation rules are exce=
llent examples about the position and importance of these rules. Other subt=
le rules are usually more difficult to learn. That&#39;s why I think the ch=
ange harms the teachability: we&#39;d lost a chance to tell the newbies to =
discipline themselves about being responsible to what they&#39;d write, whi=
ch is hard to rescue later. This is super important for a language has so m=
any traps to use.<br><br>There are more details about the rules, e.g. I thi=
nk <a href=3D"http://wg21.cmeerw.net/cwg/issue222" target=3D"_blank">CWG222=
 </a>is a good change. It also loose the requirements on user code, but it =
does not have the drawbacks above, esp. it did not introduce the confusions=
 like above.<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font><=
/span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1143fae07236af0526156220--

.

On 2015-12-04 04:52, FrankHB1989 wrote:
> I am seriously against P0145R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf>.
> As a user of C++, I urge EWG and CWG to reconsider the reasons to adopt
> this proposal.
>
> To be systemic, here are my reasons:
>
>  1. It is a breaking change.

Not really. Code that works now continue to work, with the same result.

>  2. It complicates the language itself. (If in doubt, compare the
>     wording, please.)

This doesn't seem to be a big problem for the C++ language. It is simple
now, and this change will make it complicated?

>  3. As mentioned above, it may harm to optimization.

Not really. Code that works properly now can still be as optimized as
before. The compiler just has to enure that the result is "as-if" it had
followed the new rules.

Right now the code has to work with ANY evaluation order. With such code
the compiler can continue to use its best evaluation order.

>  4. The reason represented by the proposal is unsound. It harms
>     teachability and makes it hard to get consensus on conventional
>     ("best") practice.
>

What is best practice might change as a result of this proposal. :-)

I also belive that a defined order of evaluation, if anything, will make
it EASIER to teach how a multi-parameter function call works.


    Bo Persson


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 12/04/2015 06:05 PM, Bo Persson wrote:
> On 2015-12-04 04:52, FrankHB1989 wrote:
>> I am seriously against P0145R0
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf>.
>> As a user of C++, I urge EWG and CWG to reconsider the reasons to adopt
>> this proposal.
>>
>> To be systemic, here are my reasons:
>>
>>  1. It is a breaking change.
>
> Not really. Code that works now continue to work, with the same result.

Agreed.

>>  3. As mentioned above, it may harm to optimization.
>
> Not really. Code that works properly now can still be as optimized as
> before. The compiler just has to enure that the result is "as-if" it had
> followed the new rules.

Yes, but observing the "as-if" does introduce a constraint to the
optimizer that wasn't there before.  (For example, x86 32bit Linux
calling conventions seem to require right-to-left arguments on
the stack.  Is the extra reordering causing noticeable harm to
the generated code?)

> Right now the code has to work with ANY evaluation order. With such code
> the compiler can continue to use its best evaluation order.

I don't understand this remark in view of P0145R0.

>>  4. The reason represented by the proposal is unsound. It harms
>>     teachability and makes it hard to get consensus on conventional
>>     ("best") practice.
>>
>
> What is best practice might change as a result of this proposal. :-)
>
> I also belive that a defined order of evaluation, if anything, will make
> it EASIER to teach how a multi-parameter function call works.

I'd like to point out that the specific examples presented in the
paper (so far) do not make a point for fixed order-of-evaluation of
function arguments. They do argue for ordering in cases such as
x.y and x->y, though.

Personally, function arguments in source code look a lot less
ordered to me than class member access, for example.

Jens

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

I can't imagine the standards committee ever accepting this proposal. The
optimization concerns alone are enough to dismiss it.

On Thursday, December 3, 2015, FrankHB1989 <frankhb1989@gmail.com> wrote:

> I am seriously against P0145R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf>. As
> a user of C++, I urge EWG and CWG to reconsider the reasons to adopt this
> proposal.
>
> To be systemic, here are my reasons:
>
>    1. It is a breaking change.
>    2. It complicates the language itself. (If in doubt, compare the
>    wording, please.)
>    3. As mentioned above, it may harm to optimization.
>    4. The reason represented by the proposal is unsound. It harms
>    teachability and makes it hard to get consensus on conventional ("best")
>    practice.
>
> I feels the first 2 points should be acknowledged here.
>
> To the 3rd point, one key point I'd note here is: *this change forbids a
> portable way to easily express the unsequenced evaluation of an expression* *intended
> *by the author of the code.
>
> For this purpose, I currently explicitly used the unsequenced function
> parameter rule
> <https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=master&fileviewer=file-view-default#ydef.h-938>
> and a macro wrapper
> <https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=master&fileviewer=file-view-default#ydef.h-956>
> for readability. (It would probably be better with PR0146R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html>.)
> However, the change by this proposal makes it a joke.
>
> Specifically, I can, but don't want to:
>
> // Not portable!
> #pragma GCC diagnostic push
> #pragma GCC diagnostic warning "-std=c++11" // Huh, is it documented?
> // ...
> #pragma GCC diagnostic pop
>
> For the 4th point, one key point is: *it is nonsense to support bad code*.
>
> If the author want the clear evaluation order, do extract the
> subexpression as a single statement (followed by ';'). This transformation
> should not be a problem on well-formed code since even constexpr functions
> now support multiple statements in the body, and there are lambdas.
>
> What if the author do not know what order they want ... who allow they to
> code such spaghetti?
>
> I don't think anyone should be encourage to write such code except for the
> purpose of testing the implementation (e.g. [-Wsequenced] or ubsan). Any
> senior C++ user would probable agree this point easily by their experience.
> The code should be reject by the contemporary style because it causes
> confusion. The suggestion of change itself also has caused such problem,
> see comments on Herb Sutter's poll
> <http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation>.
>
> To reduce the potential risks, a programmer who don't have enough common
> sense about sequence rules (also imply the definition of "undefined
> behavior"), should not be granted permission of modify the C++ code base in
> a serious project. This is similar to C which uses similar UB rules with
> "sequence point" wording. *These knowledge should be at very basic level
> of the language.* The unsequenced evaluation rules are excellent examples
> about the position and importance of these rules. Other subtle rules are
> usually more difficult to learn. That's why I think the change harms the
> teachability: we'd lost a chance to tell the newbies to discipline
> themselves about being responsible to what they'd write, which is hard to
> rescue later. This is super important for a language has so many traps to
> use.
>
> There are more details about the rules, e.g. I think CWG222
> <http://wg21.cmeerw.net/cwg/issue222>is a good change. It also loose the
> requirements on user code, but it does not have the drawbacks above, esp.
> it did not introduce the confusions like above.
>
> --
>
> ---
> You received this message because you are 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
> <javascript:_e(%7B%7D,'cvml','std-proposals%2Bunsubscribe@isocpp.org');>.
> To post to this group, send email to std-proposals@isocpp.org
> <javascript:_e(%7B%7D,'cvml','std-proposals@isocpp.org');>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

I can&#39;t imagine the standards committee ever accepting this proposal. T=
he optimization concerns alone are enough to dismiss it.<br><br>On Thursday=
, December 3, 2015, FrankHB1989 &lt;<a href=3D"mailto:frankhb1989@gmail.com=
">frankhb1989@gmail.com</a>&gt; wrote:<br><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">I am seriously against <a href=3D"http://www.open-std.org/jt=
c1/sc22/wg21/docs/papers/2015/p0145r0.pdf" target=3D"_blank">P0145R0</a>. A=
s a user of C++, I urge EWG and CWG to reconsider the reasons to adopt this=
 proposal.<br><br>To be systemic, here are my reasons:<br><ol><li>It is a b=
reaking change.</li><li>It complicates the language itself. (If in doubt, c=
ompare the wording, please.)</li><li>As mentioned above, it may harm to opt=
imization.</li><li>The reason represented by the proposal is unsound. It ha=
rms teachability and makes it hard to get consensus on conventional (&quot;=
best&quot;) practice.<br></li></ol>I feels the first 2 points should be ack=
nowledged here.<br><br>To the 3rd point, one key point I&#39;d note here is=
: <b>this change forbids a portable way to easily express the unsequenced e=
valuation of an expression</b> <i>intended </i>by the author of the code.<b=
r><br>For this purpose, I currently explicitly <a href=3D"https://bitbucket=
..org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/inclu=
de/ydef.h?at=3Dmaster&amp;fileviewer=3Dfile-view-default#ydef.h-938" target=
=3D"_blank">used the unsequenced function parameter rule</a> and <a href=3D=
"https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92f=
e2d256/YBase/include/ydef.h?at=3Dmaster&amp;fileviewer=3Dfile-view-default#=
ydef.h-956" target=3D"_blank">a macro wrapper</a> for readability. (It woul=
d probably be better with <a href=3D"http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2015/p0146r0.html" target=3D"_blank">PR0146R0</a>.) However, t=
he change by this proposal makes it a joke.<br><br>Specifically, I can, but=
 don&#39;t want to:<br><br><div 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:#800"><code><div><span style=
=3D"color:#800">// Not portable!<br>#pragma</span><span style=3D"color:#000=
"> GCC diagnostic push<br></span></div></code>#pragma</span><span style=3D"=
color:#000"> GCC diagnostic warning </span><span style=3D"color:#080">&quot=
;-std=3Dc++11&quot;</span><span style=3D"color:#000"> </span><span style=3D=
"color:#800">// Huh, is it documented?<br>// ...</span><span style=3D"color=
:#000"><br></span><span style=3D"color:#800">#pragma</span><span style=3D"c=
olor:#000"> GCC diagnostic pop<br></span></div></code></div><br>For the 4th=
 point, one key point is: <b>it is nonsense to support bad code</b>.<br><br=
>If the author want the clear evaluation order, do extract the subexpressio=
n as a single statement (followed by &#39;;&#39;). This transformation shou=
ld not be a problem on well-formed code since even constexpr functions now =
support multiple statements in the body, and there are lambdas.<br><br>What=
 if the author do not know what order they want ... who allow they to code =
such spaghetti?<br><br>I don&#39;t think anyone should be encourage to writ=
e such code except for the purpose of testing the implementation (e.g. [-Ws=
equenced] or ubsan). Any senior C++ user would probable agree this point ea=
sily by their experience. The code should be reject by the contemporary sty=
le because it causes confusion.
 The suggestion of change itself also has caused such problem, see=20
comments on <a href=3D"http://herbsutter.com/2014/12/01/a-quick-poll-about-=
order-of-evaluation" target=3D"_blank">Herb Sutter&#39;s poll</a>.<br><br>T=
o reduce the potential risks, a programmer who don&#39;t have enough common=
 sense about sequence rules (also imply the definition of &quot;undefined b=
ehavior&quot;), should not be granted permission of modify the C++ code bas=
e in a serious project. This is similar to C which uses similar UB rules wi=
th &quot;sequence point&quot; wording. <b>These knowledge should be at very=
 basic level of the language.</b> The unsequenced evaluation rules are exce=
llent examples about the position and importance of these rules. Other subt=
le rules are usually more difficult to learn. That&#39;s why I think the ch=
ange harms the teachability: we&#39;d lost a chance to tell the newbies to =
discipline themselves about being responsible to what they&#39;d write, whi=
ch is hard to rescue later. This is super important for a language has so m=
any traps to use.<br><br>There are more details about the rules, e.g. I thi=
nk <a href=3D"http://wg21.cmeerw.net/cwg/issue222" target=3D"_blank">CWG222=
 </a>is a good change. It also loose the requirements on user code, but it =
does not have the drawbacks above, esp. it did not introduce the confusions=
 like above.<br><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;std-proposals%2=
Bunsubscribe@isocpp.org&#39;);" target=3D"_blank">std-proposals+unsubscribe=
@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:_e(%7B%7D,&#39;c=
vml&#39;,&#39;std-proposals@isocpp.org&#39;);" target=3D"_blank">std-propos=
als@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2c23c0e4c7e05261a41d8--

.

------=_Part_1705_1712977851.1449328394309
Content-Type: multipart/alternative;
 boundary="----=_Part_1706_24231133.1449328394309"

------=_Part_1706_24231133.1449328394309
Content-Type: text/plain; charset=UTF-8

In Friday, December 4, 2015 at 5:44:47 PM UTC-5, Trevor Hickey wrote:
>
> I can't imagine the standards committee ever accepting this proposal. The
> optimization concerns alone are enough to dismiss it.
>

It's passed EWG
<https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
at Kona <https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report>.
That doesn't mean it can't come back if there is sufficient outcry, but the
committee didn't seem to think it was a problem.

So perhaps you need a better imagination ;)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">In Friday, December 4, 2015 at 5:44:47 PM UTC-5, Trevor Hi=
ckey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I can&#39;t imagine=
 the standards committee ever accepting this proposal. The optimization con=
cerns alone are enough to dismiss it.<br></blockquote><div><br>It&#39;s <a =
href=3D"https://botondballo.wordpress.com/2015/11/09/trip-report-c-standard=
s-meeting-in-kona-october-2015/">passed EWG</a> at <a href=3D"https://isocp=
p.org/blog/2015/11/kona-standards-meeting-trip-report">Kona</a>. That doesn=
&#39;t mean it can&#39;t come back if there is sufficient outcry, but the c=
ommittee didn&#39;t seem to think it was a problem.<br><br>So perhaps you n=
eed a better imagination ;)</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1706_24231133.1449328394309--
------=_Part_1705_1712977851.1449328394309--

.

------=_Part_19_503874969.1449329224568
Content-Type: multipart/alternative;
 boundary="----=_Part_20_133966398.1449329224568"

------=_Part_20_133966398.1449329224568
Content-Type: text/plain; charset=UTF-8



On Saturday, December 5, 2015 at 4:13:14 PM UTC+1, Nicol Bolas wrote:
>
> In Friday, December 4, 2015 at 5:44:47 PM UTC-5, Trevor Hickey wrote:
>>
>> I can't imagine the standards committee ever accepting this proposal. The
>> optimization concerns alone are enough to dismiss it.
>>
>
> It's passed EWG
> <https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
> at Kona
> <https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report>.
> That doesn't mean it can't come back if there is sufficient outcry, but the
> committee didn't seem to think it was a problem.
>
> So perhaps you need a better imagination ;)
>

Probably best way is simply test if this have any real disadvantage when
order of evaluation is fix in place. We could easy compare same application
with or without it compiled by same compiler.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Saturday, December 5, 2015 at 4:13:14 PM UTC+1, Nicol Bolas wrot=
e:<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">In Friday, =
December 4, 2015 at 5:44:47 PM UTC-5, Trevor Hickey wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">I can&#39;t imagine the standards committee ever acc=
epting this proposal. The optimization concerns alone are enough to dismiss=
 it.<br></blockquote><div><br>It&#39;s <a href=3D"https://botondballo.wordp=
ress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/" =
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://=
www.google.com/url?q\75https%3A%2F%2Fbotondballo.wordpress.com%2F2015%2F11%=
2F09%2Ftrip-report-c-standards-meeting-in-kona-october-2015%2F\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNH0fDsHBDmgIXlDvga9RNUVFObifw&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fbotond=
ballo.wordpress.com%2F2015%2F11%2F09%2Ftrip-report-c-standards-meeting-in-k=
ona-october-2015%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNH0fDsHBDmgIXlDvga9RN=
UVFObifw&#39;;return true;">passed EWG</a> at <a href=3D"https://isocpp.org=
/blog/2015/11/kona-standards-meeting-trip-report" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75ht=
tps%3A%2F%2Fisocpp.org%2Fblog%2F2015%2F11%2Fkona-standards-meeting-trip-rep=
ort\46sa\75D\46sntz\0751\46usg\75AFQjCNEqYLuQO11BCv_AYTNRcsyrE0KXnQ&#39;;re=
turn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75http=
s%3A%2F%2Fisocpp.org%2Fblog%2F2015%2F11%2Fkona-standards-meeting-trip-repor=
t\46sa\75D\46sntz\0751\46usg\75AFQjCNEqYLuQO11BCv_AYTNRcsyrE0KXnQ&#39;;retu=
rn true;">Kona</a>. That doesn&#39;t mean it can&#39;t come back if there i=
s sufficient outcry, but the committee didn&#39;t seem to think it was a pr=
oblem.<br><br>So perhaps you need a better imagination ;)</div></div></bloc=
kquote><div><br>Probably best way is simply test if this have any real disa=
dvantage when order of evaluation is fix in place. We could easy compare sa=
me application with or without it compiled by same compiler.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_20_133966398.1449329224568--
------=_Part_19_503874969.1449329224568--

.

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

On Friday, 4 December 2015 16:56:15 UTC, Hyman Rosen  wrote:
> P0145R0 is bad for two reasons.=C2=A0 First, it (deliberately) does not s=
pecify a fixed order of evaluation for all expressions (thereby failing to =
solve the problem it ostensibly addresses), and second, it does not specify=
 that the order should always be strictly left-to-right (thereby failing to=
 provide a rule which is simple to understand). =C2=A0(Point 2 above is thu=
s a consequence.)
>=20
> Point 1 above is wrong.=C2=A0 A change that specifies behavior formerly u=
nspecified cannot be breaking.=C2=A0 Implementations that have made promise=
s beyond what the standard offers can be broken, but that is not the proble=
m of the committee.=C2=A0 Programmers who relied on their implementation's =
order are, as per Point 4 above, to be scorned.
>=20
>=20
>=20
> Point 4 above places the cart squarely in front of the horse.=C2=A0 The r=
eason programmers have so much trouble with the existing rules is that the =
existing rules are stupid.=C2=A0 The way to fix the situation is to fix the=
 stupid rules, not to treat them as a pons asinorum=C2=A0so that smug super=
iority can be asserted.=C2=A0 The code would not be bad if the language had=
 correct rules.
>=20
> Point 4 prime, that programmers wish to indicate that they do not care ab=
out order, is, to continue the animal metaphors, a red herring.=C2=A0 How, =
for example, given two functions void f(); and void g();, how would you ind=
icate that you want them called unsequenced?

If you really want to, [](...){}((f(), 0), (g(), 0));.

It seems rather unlikely that you would want to, as functions returning voi=
d are called for their side effects.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_268_1093377010.1449333181902--

.

------=_Part_3801_277923161.1449391394223
Content-Type: multipart/alternative;
 boundary="----=_Part_3802_1926348293.1449391394224"

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

Sorry for occasional deletion of the original post ...

=E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=8812:56:15=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> P0145R0 is bad for two reasons.  First, it (deliberately) does not specif=
y=20
> a fixed order of evaluation for all expressions (thereby failing to solve=
=20
> the problem it ostensibly addresses), and second, it does not specify tha=
t=20
> the order should always be strictly left-to-right (thereby failing to=20
> provide a rule which is simple to understand).  (Point 2 above is thus a=
=20
> consequence.)
>
> This is not totally consequence of the design of the rules or approach of=
=20
the wording. The root reason is "left-to-right" is essentially and=20
naturally more complicated than "unsequenced" (you'd define what is "left"=
=20
and what is "right"). And you can't remove "unsequenced" rules away at all,=
=20
because there are other use of them. So the result is, you need more words=
=20
to clarify it, always more wordy.
=20

> Point 1 above is wrong.  A change that specifies behavior formerly=20
> unspecified cannot be breaking.  Implementations that have made promises=
=20
> beyond what the standard offers can be broken, but that is not the proble=
m=20
> of the committee.  Programmers who relied on their implementation's order=
=20
> are, as per Point 4 above, to be scorned.
>
> This *is *a breaking change *to implementations*. Even if the=20
implementation did not promise anything beyond the standard to the user,=20
the conforming status could be broken in the sense of new stricter rules=20
silently, because not all currently conforming implementations obey the new=
=20
rules. Thus, *it is forcing potentially more work on current=20
implementations*. It would make problems not existed before.
=20

> Point 4 above places the cart squarely in front of the horse.  The reason=
=20
> programmers have so much trouble with the existing rules is that the=20
> existing rules are stupid.=20
>

I don't find it reasonable. These programmers would have more=20
trouble.because new rules are more specific and complicated. And I am sure=
=20
who have no trouble before could have trouble since they need more effort=
=20
to keep there original intent on the code.

The way to fix the situation is to fix the stupid rules, not to treat them=
=20
> as a *pons asinorum* so that smug superiority can be asserted.  The code=
=20
> would not be bad if the language had correct rules.
>
> There is no need and no way to "fix" at all. Whatever you proposed to=20
change, the change itself makes it more difficult to learn, because old=20
rules are still technically correct and would be with contemporary=20
implementation for a long time. How can newbies ignore the old rules? How=
=20
do they figure out whether there are bugs in the old code with the change=
=20
of the rules? Or how do they avoid old code totally? For a language like=20
C++, no way, practically. They would eventually require to learn the old=20
rules, plus the new one. That is, you'd actually build another *pons=20
asinorum*, and harm every sane users. The change itself is more stupid than=
=20
any choice of the rules.
=20

> Point 4 prime, that programmers wish to indicate that they do not care=20
> about order, is, to continue the animal metaphors, a red herring.  How, f=
or=20
> example, given two functions void f(); and void g();, how would you=20
> indicate that you want them called unsequenced?
>
> You did not get the point. The "unsequenced" is an adjective on=20
evaluations. It is nonsense to talk about "unsequenced functions" without a=
=20
concrete syntactic context, which makes some expressions (e.g. function=20
names as id expressions, or function calls as postfix expressions) are=20
evaluated.
=20

> That leaves optimization.  In the old days, when parameters were passed o=
n=20
> the stack, left-to-right evaluation might have led to some pessimization.=
 =20
> But modern architectures pass arguments in registers, so that no longer=
=20
> matters.  Nevertheless, I do expect the proponents of the status quo to=
=20
> start pulling out examples where some compiler produces worse code, becau=
se=20
> that's what they always do - this argument has been going on for decades.=
 =20
> The Max Planck paraphrase that "science progresses one funeral at a time"=
=20
> has never been more true.
>
> Actually, optimization here is the least important point in my mind,=20
because of the effect of "as-if" rules is not weakened. The point still=20
makes sense because in aspect of the expression power, the change makes us=
=20
gain nothing, but likely lost some possibilities. This is a sign of bad=20
language design.

You should better distinct the abstract machine semantics and the semantics=
=20
on actual implementations, i.e. "allowed to do" vs. "would do". The=20
language itself does not specify that the activation records should be a=20
call stack. It also cares nothing about order of "passing" of the=20
parameters, which is *not *the evaluation order on expressions. This=20
"order" is just out of the scope. Even for typical implementations, passing=
=20
parameters does not matter much and would be no sense once the=20
inter-procedural optimization is performed and these operations would be=20
optimized away, thus this "order" is again nonsense, at least in aspect of=
=20
"optimization"/performance (but probably not true for ABI=20
compatibility/semantics specified by some extensions).

=20

> On Thu, Dec 3, 2015 at 10:52 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>
>> I am seriously against P0145R0=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf>.=
=20
>> As a user of C++, I urge EWG and CWG to reconsider the reasons to adopt=
=20
>> this proposal.
>>
>> To be systemic, here are my reasons:
>>
>>    1. It is a breaking change.
>>    2. It complicates the language itself. (If in doubt, compare the=20
>>    wording, please.)
>>    3. As mentioned above, it may harm to optimization.
>>    4. The reason represented by the proposal is unsound. It harms=20
>>    teachability and makes it hard to get consensus on conventional ("bes=
t")=20
>>    practice.
>>   =20
>> I feels the first 2 points should be acknowledged here.
>>
>> To the 3rd point, one key point I'd note here is: *this change forbids a=
=20
>> portable way to easily express the unsequenced evaluation of an expressi=
on* *intended=20
>> *by the author of the code.
>>
>> For this purpose, I currently explicitly used the unsequenced function=
=20
>> parameter rule=20
>> <https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae=
92fe2d256/YBase/include/ydef.h?at=3Dmaster&fileviewer=3Dfile-view-default#y=
def.h-938>=20
>> and a macro wrapper=20
>> <https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae=
92fe2d256/YBase/include/ydef.h?at=3Dmaster&fileviewer=3Dfile-view-default#y=
def.h-956>=20
>> for readability. (It would probably be better with PR0146R0=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html>.)=
=20
>> However, the change by this proposal makes it a joke.
>>
>> Specifically, I can, but don't want to:
>>
>> // Not portable!
>> #pragma GCC diagnostic push
>> #pragma GCC diagnostic warning "-std=3Dc++11" // Huh, is it documented?
>> // ...
>> #pragma GCC diagnostic pop
>>
>> For the 4th point, one key point is: *it is nonsense to support bad code=
*
>> .
>>
>> If the author want the clear evaluation order, do extract the=20
>> subexpression as a single statement (followed by ';'). This transformati=
on=20
>> should not be a problem on well-formed code since even constexpr functio=
ns=20
>> now support multiple statements in the body, and there are lambdas.
>>
>> What if the author do not know what order they want ... who allow they t=
o=20
>> code such spaghetti?
>>
>> I don't think anyone should be encourage to write such code except for=
=20
>> the purpose of testing the implementation (e.g. [-Wsequenced] or ubsan).=
=20
>> Any senior C++ user would probable agree this point easily by their=20
>> experience. The code should be reject by the contemporary style because =
it=20
>> causes confusion. The suggestion of change itself also has caused such=
=20
>> problem, see comments on Herb Sutter's poll=20
>> <http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation=
>
>> .
>>
>> To reduce the potential risks, a programmer who don't have enough common=
=20
>> sense about sequence rules (also imply the definition of "undefined=20
>> behavior"), should not be granted permission of modify the C++ code base=
 in=20
>> a serious project. This is similar to C which uses similar UB rules with=
=20
>> "sequence point" wording. *These knowledge should be at very basic level=
=20
>> of the language.* The unsequenced evaluation rules are excellent=20
>> examples about the position and importance of these rules. Other subtle=
=20
>> rules are usually more difficult to learn. That's why I think the change=
=20
>> harms the teachability: we'd lost a chance to tell the newbies to=20
>> discipline themselves about being responsible to what they'd write, whic=
h=20
>> is hard to rescue later. This is super important for a language has so m=
any=20
>> traps to use.
>>
>> There are more details about the rules, e.g. I think CWG222=20
>> <http://wg21.cmeerw.net/cwg/issue222>is a good change. It also loose the=
=20
>> requirements on user code, but it does not have the drawbacks above, esp=
..=20
>> it did not introduce the confusions like above.
>>
>> --=20
>>
>> ---=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:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>



=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Sorry for occasional deletion of the original post ...<br>=
<br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD=
 UTC+8=E4=B8=8A=E5=8D=8812:56:15=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.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">P0145R0=
 is bad for two reasons.=C2=A0 First, it (deliberately) does not specify a =
fixed order of evaluation for all expressions (thereby failing to solve the=
 problem it ostensibly addresses), and second, it does not specify that the=
 order should always be strictly left-to-right (thereby failing to provide =
a rule which is simple to understand). =C2=A0(Point 2 above is thus a conse=
quence.)<br><br></div></blockquote><div>This is not totally consequence of =
the design of the rules or=20
approach of the wording. The root reason is &quot;left-to-right&quot; is=20
essentially and naturally more complicated than &quot;unsequenced&quot; (yo=
u&#39;d=20
define what is &quot;left&quot; and what is &quot;right&quot;). And you can=
&#39;t remove=20
&quot;unsequenced&quot; rules away at all, because there are other use of t=
hem. So
 the result is, you need more words to clarify it, always more wordy.<br>=
=C2=A0</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">P=
oint 1 above is wrong.=C2=A0 A change that specifies behavior formerly unsp=
ecified cannot be breaking.=C2=A0 Implementations that have made promises b=
eyond what the standard offers can be broken, but that is not the problem o=
f the committee.=C2=A0 Programmers who relied on their implementation&#39;s=
 order are, as per Point 4 above, to be scorned.<br><div><br></div></div></=
blockquote><div>This <i>is </i>a breaking change <b>to implementations</b>.=
 Even if=20
the implementation did not promise anything beyond the standard to the=20
user, the conforming status could be broken in the sense of new stricter
 rules silently, because not all currently conforming implementations=20
obey the new rules. Thus, <b>it is forcing potentially more work on current=
 implementations</b>. It would make problems not existed before.<br>=C2=A0<=
/div><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></d=
iv><div>Point 4 above places the cart squarely in front of the horse.=C2=A0=
 The reason programmers have so much trouble with the existing rules is tha=
t the existing rules are stupid. </div></div></blockquote><div><br>I don&#3=
9;t find it reasonable. These programmers would have more trouble.because n=
ew rules are more specific and complicated. And I am sure who have no troub=
le before could have trouble since they need more effort to keep there orig=
inal intent on the code.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div>The way to fix the situation is to fix the st=
upid rules, not to treat them as a <i>pons asinorum</i>=C2=A0so that smug s=
uperiority can be asserted.=C2=A0 The code would not be bad if the language=
 had correct rules.<br><br></div></div></blockquote><div>There is no need a=
nd no way to &quot;fix&quot; at all. Whatever you proposed to change, the c=
hange itself makes it more difficult to learn, because old rules are still =
technically correct and would be with contemporary implementation for a lon=
g time. How can newbies ignore the old rules? How do they figure out whethe=
r there are bugs in the old code with the change of the rules? Or how do th=
ey avoid old code totally? For a language like C++, no way, practically. Th=
ey would eventually require to learn the old rules, plus the new one. That =
is, you&#39;d actually build another <i>pons asinorum</i>, and harm every s=
ane users. The change itself is more stupid than any choice of the rules.<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>Point 4 prime, that programmers wish to indicate that they do not=
 care about order, is, to continue the animal metaphors, a red herring.=C2=
=A0 How, for example, given two functions <font face=3D"monospace, monospac=
e">void f();</font> and <font face=3D"monospace, monospace">void g();</font=
>, how would you indicate that you want them called unsequenced?<br><br></d=
iv></div></blockquote><div>You did not get the point. The &quot;unsequenced=
&quot; is an adjective on evaluations. It is nonsense to talk about &quot;u=
nsequenced functions&quot; without a concrete syntactic context, which make=
s some expressions (e.g. function names as id expressions, or function call=
s as postfix expressions) are evaluated.<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>That leaves optimizatio=
n.=C2=A0 In the old days, when parameters were passed on the stack, left-to=
-right evaluation might have led to some pessimization.=C2=A0 But modern ar=
chitectures pass arguments in registers, so that no longer matters.=C2=A0 N=
evertheless, I do expect the proponents of the status quo to start pulling =
out examples where some compiler produces worse code, because that&#39;s wh=
at they always do - this argument has been going on for decades.=C2=A0 The =
Max Planck paraphrase that &quot;science progresses one funeral at a time&q=
uot; has never been more true.<br></div></div><div><br></div></blockquote><=
div>Actually, optimization here is the least important point in my mind, be=
cause of the effect of &quot;as-if&quot; rules is not weakened. The point s=
till makes sense because in aspect of the expression power, the change make=
s us gain nothing, but likely lost some possibilities. This is a sign of ba=
d language design.<br><br>You should better distinct the abstract machine s=
emantics and the semantics on actual implementations, i.e. &quot;allowed to=
 do&quot; vs. &quot;would do&quot;. The language itself does not specify th=
at the activation records should be a call stack. It also cares nothing abo=
ut order of &quot;passing&quot; of the parameters, which is <b>not </b>the =
evaluation order on expressions. This &quot;order&quot; is just out of the =
scope. Even for typical implementations, passing parameters does not matter=
 much and would be no sense once the inter-procedural optimization is perfo=
rmed and these operations would be optimized away, thus this &quot;order&qu=
ot; is again nonsense, at least in aspect of &quot;optimization&quot;/perfo=
rmance (but probably not true for ABI compatibility/semantics specified by =
some extensions).<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-l=
eft: 1ex;"><div><div class=3D"gmail_quote">On Thu, Dec 3, 2015 at 10:52 PM,=
 FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"z4YttJCVCQAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;j=
avascript:&#39;;return true;">frank...@gmail.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">I am seriously against <a hr=
ef=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf" =
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://w=
ww.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2F=
docs%2Fpapers%2F2015%2Fp0145r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEbZmJ=
OL_yEiq8zVZJqtZDlIWhk2w&#39;;return true;" onclick=3D"this.href=3D&#39;http=
://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg2=
1%2Fdocs%2Fpapers%2F2015%2Fp0145r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
bZmJOL_yEiq8zVZJqtZDlIWhk2w&#39;;return true;">P0145R0</a>. As a user of C+=
+, I urge EWG and CWG to reconsider the reasons to adopt this proposal.<br>=
<br>To be systemic, here are my reasons:<br><ol><li>It is a breaking change=
..</li><li>It complicates the language itself. (If in doubt, compare the wor=
ding, please.)</li><li>As mentioned above, it may harm to optimization.</li=
><li>The reason represented by the proposal is unsound. It harms teachabili=
ty and makes it hard to get consensus on conventional (&quot;best&quot;) pr=
actice.<br></li></ol>I feels the first 2 points should be acknowledged here=
..<br><br>To the 3rd point, one key point I&#39;d note here is: <b>this chan=
ge forbids a portable way to easily express the unsequenced evaluation of a=
n expression</b> <i>intended </i>by the author of the code.<br><br>For this=
 purpose, I currently explicitly <a href=3D"https://bitbucket.org/FrankHB/y=
slib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=
=3Dmaster&amp;fileviewer=3Dfile-view-default#ydef.h-938" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url=
?q\75https%3A%2F%2Fbitbucket.org%2FFrankHB%2Fyslib%2Fsrc%2F82a019b2ec3a51c3=
2a92ceb674020ae92fe2d256%2FYBase%2Finclude%2Fydef.h%3Fat%3Dmaster%26filevie=
wer%3Dfile-view-default%23ydef.h-938\46sa\75D\46sntz\0751\46usg\75AFQjCNFRC=
b0hjjLwInQ3LUpfhH0-e_JjsA&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\75https%3A%2F%2Fbitbucket.org%2FFrankHB%2Fyslib%=
2Fsrc%2F82a019b2ec3a51c32a92ceb674020ae92fe2d256%2FYBase%2Finclude%2Fydef.h=
%3Fat%3Dmaster%26fileviewer%3Dfile-view-default%23ydef.h-938\46sa\75D\46snt=
z\0751\46usg\75AFQjCNFRCb0hjjLwInQ3LUpfhH0-e_JjsA&#39;;return true;">used t=
he unsequenced function parameter rule</a> and <a href=3D"https://bitbucket=
..org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/inclu=
de/ydef.h?at=3Dmaster&amp;fileviewer=3Dfile-view-default#ydef.h-956" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.go=
ogle.com/url?q\75https%3A%2F%2Fbitbucket.org%2FFrankHB%2Fyslib%2Fsrc%2F82a0=
19b2ec3a51c32a92ceb674020ae92fe2d256%2FYBase%2Finclude%2Fydef.h%3Fat%3Dmast=
er%26fileviewer%3Dfile-view-default%23ydef.h-956\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGj0tmC7XkmtIyGmuCiPBk_1Wg6sw&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fbitbucket.org%2FFran=
kHB%2Fyslib%2Fsrc%2F82a019b2ec3a51c32a92ceb674020ae92fe2d256%2FYBase%2Fincl=
ude%2Fydef.h%3Fat%3Dmaster%26fileviewer%3Dfile-view-default%23ydef.h-956\46=
sa\75D\46sntz\0751\46usg\75AFQjCNGj0tmC7XkmtIyGmuCiPBk_1Wg6sw&#39;;return t=
rue;">a macro wrapper</a> for readability. (It would probably be better wit=
h <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r=
0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0146r0.html\46sa\75D\46sntz\0751\46usg\75AF=
QjCNGFFGHgHIThkaWY3MV5oL4IIccqCA&#39;;return true;" onclick=3D"this.href=3D=
&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fs=
c22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0146r0.html\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIccqCA&#39;;return true;">PR0146R0</a>.) How=
ever, the change by this proposal makes it a joke.<br><br>Specifically, I c=
an, but don&#39;t want to:<br><br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wo=
rd-wrap:break-word"><code><div><span style=3D"color:#800"><code><div><span =
style=3D"color:#800">// Not portable!<br>#pragma</span><span style=3D"color=
:#000"> GCC diagnostic push<br></span></div></code>#pragma</span><span styl=
e=3D"color:#000"> GCC diagnostic warning </span><span style=3D"color:#080">=
&quot;-std=3Dc++11&quot;</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#800">// Huh, is it documented?<br>// ...</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#800">#pragma</span><span style=
=3D"color:#000"> GCC diagnostic pop<br></span></div></code></div><br>For th=
e 4th point, one key point is: <b>it is nonsense to support bad code</b>.<b=
r><br>If the author want the clear evaluation order, do extract the subexpr=
ession as a single statement (followed by &#39;;&#39;). This transformation=
 should not be a problem on well-formed code since even constexpr functions=
 now support multiple statements in the body, and there are lambdas.<br><br=
>What if the author do not know what order they want ... who allow they to =
code such spaghetti?<br><br>I don&#39;t think anyone should be encourage to=
 write such code except for the purpose of testing the implementation (e.g.=
 [-Wsequenced] or ubsan). Any senior C++ user would probable agree this poi=
nt easily by their experience. The code should be reject by the contemporar=
y style because it causes confusion.
 The suggestion of change itself also has caused such problem, see=20
comments on <a href=3D"http://herbsutter.com/2014/12/01/a-quick-poll-about-=
order-of-evaluation" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fherbsutter.com%2F20=
14%2F12%2F01%2Fa-quick-poll-about-order-of-evaluation\46sa\75D\46sntz\0751\=
46usg\75AFQjCNF93Wsu5EyVb6nOPCTJFJOZ_bot3A&#39;;return true;" onclick=3D"th=
is.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fherbsutter.com%2F=
2014%2F12%2F01%2Fa-quick-poll-about-order-of-evaluation\46sa\75D\46sntz\075=
1\46usg\75AFQjCNF93Wsu5EyVb6nOPCTJFJOZ_bot3A&#39;;return true;">Herb Sutter=
&#39;s poll</a>.<br><br>To reduce the potential risks, a programmer who don=
&#39;t have enough common sense about sequence rules (also imply the defini=
tion of &quot;undefined behavior&quot;), should not be granted permission o=
f modify the C++ code base in a serious project. This is similar to C which=
 uses similar UB rules with &quot;sequence point&quot; wording. <b>These kn=
owledge should be at very basic level of the language.</b> The unsequenced =
evaluation rules are excellent examples about the position and importance o=
f these rules. Other subtle rules are usually more difficult to learn. That=
&#39;s why I think the change harms the teachability: we&#39;d lost a chanc=
e to tell the newbies to discipline themselves about being responsible to w=
hat they&#39;d write, which is hard to rescue later. This is super importan=
t for a language has so many traps to use.<br><br>There are more details ab=
out the rules, e.g. I think <a href=3D"http://wg21.cmeerw.net/cwg/issue222"=
 target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://=
www.google.com/url?q\75http%3A%2F%2Fwg21.cmeerw.net%2Fcwg%2Fissue222\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEFOIaLMKNmNSDLX88hzoY2veNDpg&#39;;return true;=
" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwg=
21.cmeerw.net%2Fcwg%2Fissue222\46sa\75D\46sntz\0751\46usg\75AFQjCNEFOIaLMKN=
mNSDLX88hzoY2veNDpg&#39;;return true;">CWG222 </a>is a good change. It also=
 loose the requirements on user code, but it does not have the drawbacks ab=
ove, esp. it did not introduce the confusions like above.<span><font color=
=3D"#888888"><br><br></font></span></div><span><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
z4YttJCVCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;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"z4YttJCVCQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</font></span></blockquote></div><br></div></blockquote><div><br><br><br><b=
r></div><div>=C2=A0<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3802_1926348293.1449391394224--
------=_Part_3801_277923161.1449391394223--

.

------=_Part_3911_733857386.1449392845855
Content-Type: multipart/alternative;
 boundary="----=_Part_3912_502612730.1449392845855"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=885:54:17=EF=BC=8CJens Maurer=E5=86=99=E9=81=93=EF=BC=9A
>
> On 12/04/2015 06:05 PM, Bo Persson wrote:=20
> > On 2015-12-04 04:52, FrankHB1989 wrote:=20
> >> I am seriously against P0145R0=20
> >> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf>.=
=20
> >> As a user of C++, I urge EWG and CWG to reconsider the reasons to adop=
t=20
> >> this proposal.=20
> >>=20
> >> To be systemic, here are my reasons:=20
> >>=20
> >>  1. It is a breaking change.=20
> >=20
> > Not really. Code that works now continue to work, with the same result.=
=20
>
> Agreed.=20
>
> See the reply above. This is about conformance of current implementations=
=20
in future.=20
=20

> >>  3. As mentioned above, it may harm to optimization.=20
> >=20
> > Not really. Code that works properly now can still be as optimized as=
=20
> > before. The compiler just has to enure that the result is "as-if" it ha=
d=20
> > followed the new rules.=20
>
> Yes, but observing the "as-if" does introduce a constraint to the=20
> optimizer that wasn't there before.  (For example, x86 32bit Linux=20
> calling conventions seem to require right-to-left arguments on=20
> the stack.  Is the extra reordering causing noticeable harm to=20
> the generated code?)=20
> imp
>
The order of parameter passing is not same to evaluation order on=20
expressions.

However, the optimization problem will exist in reality. The limited=20
reorder problem would occur even *before* the parameter passing, when=20
evaluating the subexpressions. Compilers are likely not happy to *prove *th=
e=20
reorder is safe in this (simpler) case, because it is generally hard to do=
=20
right, at least for C++. Even it does, this can also make the performance=
=20
of compilation worse.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=885:54:17=EF=BC=8CJens Maurer=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;">On 12/=
04/2015 06:05 PM, Bo Persson wrote:
<br>&gt; On 2015-12-04 04:52, FrankHB1989 wrote:
<br>&gt;&gt; I am seriously against P0145R0
<br>&gt;&gt; &lt;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2015/p0145r0.pdf" target=3D"_blank" rel=3D"nofollow">http://www.open-st=
d.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0145r0.pdf</a>&gt;.
<br>&gt;&gt; As a user of C++, I urge EWG and CWG to reconsider the reasons=
 to adopt
<br>&gt;&gt; this proposal.
<br>&gt;&gt;
<br>&gt;&gt; To be systemic, here are my reasons:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A01. It is a breaking change.
<br>&gt;=20
<br>&gt; Not really. Code that works now continue to work, with the same re=
sult.
<br>
<br>Agreed.
<br>
<br></blockquote><div>See the reply above. This is about conformance of cur=
rent implementations in future. <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;">&gt;&gt; =C2=A03. As mentioned above, it may harm to =
optimization.
<br>&gt;=20
<br>&gt; Not really. Code that works properly now can still be as optimized=
 as=20
<br>&gt; before. The compiler just has to enure that the result is &quot;as=
-if&quot; it had=20
<br>&gt; followed the new rules.
<br>
<br>Yes, but observing the &quot;as-if&quot; does introduce a constraint to=
 the
<br>optimizer that wasn&#39;t there before. =C2=A0(For example, x86 32bit L=
inux
<br>calling conventions seem to require right-to-left arguments on
<br>the stack. =C2=A0Is the extra reordering causing noticeable harm to
<br>the generated code?)
<br>
imp<br></blockquote><div>The order of parameter passing is not same to eval=
uation order on expressions.<br><br>However, the optimization problem will =
exist in reality. The limited reorder problem would occur even <i>before</i=
> the parameter passing, when evaluating the subexpressions. Compilers are =
likely not happy to <i>prove </i>the reorder is safe in this (simpler) case=
, because it is generally hard to do right, at least for C++. Even it does,=
 this can also make the performance of compilation worse.<br><br></div></di=
v>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3912_502612730.1449392845855--
------=_Part_3911_733857386.1449392845855--

.

------=_Part_3824_10346994.1449393360622
Content-Type: multipart/alternative;
 boundary="----=_Part_3825_2127005551.1449393360622"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC=
+8=E4=B8=8A=E5=8D=8812:33:02=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Friday, 4 December 2015 16:56:15 UTC, Hyman Rosen  wrote:=20
> > P0145R0 is bad for two reasons.  First, it (deliberately) does not=20
> specify a fixed order of evaluation for all expressions (thereby failing =
to=20
> solve the problem it ostensibly addresses), and second, it does not speci=
fy=20
> that the order should always be strictly left-to-right (thereby failing t=
o=20
> provide a rule which is simple to understand).  (Point 2 above is thus a=
=20
> consequence.)=20
> >=20
> > Point 1 above is wrong.  A change that specifies behavior formerly=20
> unspecified cannot be breaking.  Implementations that have made promises=
=20
> beyond what the standard offers can be broken, but that is not the proble=
m=20
> of the committee.  Programmers who relied on their implementation's order=
=20
> are, as per Point 4 above, to be scorned.=20
> >=20
> >=20
> >=20
> > Point 4 above places the cart squarely in front of the horse.  The=20
> reason programmers have so much trouble with the existing rules is that t=
he=20
> existing rules are stupid.  The way to fix the situation is to fix the=20
> stupid rules, not to treat them as a pons asinorum so that smug superiori=
ty=20
> can be asserted.  The code would not be bad if the language had correct=
=20
> rules.=20
> >=20
> > Point 4 prime, that programmers wish to indicate that they do not care=
=20
> about order, is, to continue the animal metaphors, a red herring.  How, f=
or=20
> example, given two functions void f(); and void g();, how would you=20
> indicate that you want them called unsequenced?=20
>
> If you really want to, [](...){}((f(), 0), (g(), 0));.=20
>
> It seems rather unlikely that you would want to, as functions returning=
=20
> void are called for their side effects.=20
>

I indeed used this approach in some generic code long ago=20
<https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92f=
e2d256/YBase/include/ystdex/functional.hpp?at=3Dmaster&fileviewer=3Dfile-vi=
ew-default#functional.hpp-241>.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E6=
=97=A5 UTC+8=E4=B8=8A=E5=8D=8812:33:02=EF=BC=8CEdward Catmur=E5=86=99=E9=81=
=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday, 4 Decem=
ber 2015 16:56:15 UTC, Hyman Rosen =C2=A0wrote:
<br>&gt; P0145R0 is bad for two reasons.=C2=A0 First, it (deliberately) doe=
s not specify a fixed order of evaluation for all expressions (thereby fail=
ing to solve the problem it ostensibly addresses), and second, it does not =
specify that the order should always be strictly left-to-right (thereby fai=
ling to provide a rule which is simple to understand). =C2=A0(Point 2 above=
 is thus a consequence.)
<br>&gt;=20
<br>&gt; Point 1 above is wrong.=C2=A0 A change that specifies behavior for=
merly unspecified cannot be breaking.=C2=A0 Implementations that have made =
promises beyond what the standard offers can be broken, but that is not the=
 problem of the committee.=C2=A0 Programmers who relied on their implementa=
tion&#39;s order are, as per Point 4 above, to be scorned.
<br>&gt;=20
<br>&gt;=20
<br>&gt;=20
<br>&gt; Point 4 above places the cart squarely in front of the horse.=C2=
=A0 The reason programmers have so much trouble with the existing rules is =
that the existing rules are stupid.=C2=A0 The way to fix the situation is t=
o fix the stupid rules, not to treat them as a pons asinorum=C2=A0so that s=
mug superiority can be asserted.=C2=A0 The code would not be bad if the lan=
guage had correct rules.
<br>&gt;=20
<br>&gt; Point 4 prime, that programmers wish to indicate that they do not =
care about order, is, to continue the animal metaphors, a red herring.=C2=
=A0 How, for example, given two functions void f(); and void g();, how woul=
d you indicate that you want them called unsequenced?
<br>
<br>If you really want to, [](...){}((f(), 0), (g(), 0));.
<br>
<br>It seems rather unlikely that you would want to, as functions returning=
 void are called for their side effects.=20
<br></blockquote><div><br>I indeed used this approach <a href=3D"https://bi=
tbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBas=
e/include/ystdex/functional.hpp?at=3Dmaster&amp;fileviewer=3Dfile-view-defa=
ult#functional.hpp-241">in some generic code long ago</a>. <br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3825_2127005551.1449393360622--
------=_Part_3824_10346994.1449393360622--

.

------=_Part_3780_1951532391.1449394069949
Content-Type: multipart/alternative;
 boundary="----=_Part_3781_1282451013.1449394069949"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=8812:56:15=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
>
> Point 4 prime, that programmers wish to indicate that they do not care=20
> about order, is, to continue the animal metaphors, a red herring.  How, f=
or=20
> example, given two functions void f(); and void g();, how would you=20
> indicate that you want them called unsequenced?
>
> Sorry, it seems that I misunderstood this paragraph. If you were talking=
=20
about the evaluation between f() and g(), see the reply above. Like in this=
=20
helper=20
<https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92f=
e2d256/YBase/include/ystdex/functional.hpp?at=3Dmaster&fileviewer=3Dfile-vi=
ew-default#functional.hpp-241>,=20
I'd probably implement it as
yunseq((f(), 0), (g(), 0))
Ugly, but still effective and somewhat readable.

Note that the evaluation between 'f' and 'g' are also unsequenced, and hard=
=20
to express by this approach. Since both 'f' and 'g' are id-expression=20
without any common subexpressions, this is safe. If not, the trick is not=
=20
usable. However, the exceptional cases are rare in C++.
=20


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=8812:56:15=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"><br><div>Point 4 prime, that programmers wish to indicate tha=
t they do not care about order, is, to continue the animal metaphors, a red=
 herring.=C2=A0 How, for example, given two functions <font face=3D"monospa=
ce, monospace">void f();</font> and <font face=3D"monospace, monospace">voi=
d g();</font>, how would you indicate that you want them called unsequenced=
?<br><br></div></div></blockquote><div>Sorry, it seems that I misunderstood=
 this paragraph. If you were talking about the evaluation between f() and g=
(), see the reply above. Like in this <a href=3D"https://bitbucket.org/Fran=
kHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ystdex=
/functional.hpp?at=3Dmaster&amp;fileviewer=3Dfile-view-default#functional.h=
pp-241">helper</a>, I&#39;d probably implement it as<div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">yunseq</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">((</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">f</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),</sp=
an><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">g</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">))</span></div></code></div>Ugly, but still effective and somewhat=
 readable.<br><br>Note that the evaluation between &#39;f&#39; and &#39;g&#=
39; are also unsequenced, and hard to express by this approach. Since both =
&#39;f&#39; and &#39;g&#39; are id-expression without any common subexpress=
ions, this is safe. If not, the trick is not usable. However, the exception=
al cases are rare in C++.<br>=C2=A0<br><br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3781_1282451013.1449394069949--
------=_Part_3780_1951532391.1449394069949--

.

------=_Part_111_423252750.1449416823996
Content-Type: multipart/alternative;
 boundary="----=_Part_112_1012955533.1449416823996"

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

On Sunday, December 6, 2015 at 3:43:14 AM UTC-5, FrankHB1989 wrote:
>
> Sorry for occasional deletion of the original post ...
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8A=E5=8D=8812:56:15=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> P0145R0 is bad for two reasons.  First, it (deliberately) does not=20
>> specify a fixed order of evaluation for all expressions (thereby failing=
 to=20
>> solve the problem it ostensibly addresses), and second, it does not spec=
ify=20
>> that the order should always be strictly left-to-right (thereby failing =
to=20
>> provide a rule which is simple to understand).  (Point 2 above is thus a=
=20
>> consequence.)
>>
>> This is not totally consequence of the design of the rules or approach o=
f=20
> the wording. The root reason is "left-to-right" is essentially and=20
> naturally more complicated than "unsequenced" (you'd define what is "left=
"=20
> and what is "right"). And you can't remove "unsequenced" rules away at al=
l,=20
> because there are other use of them. So the result is, you need more word=
s=20
> to clarify it, always more wordy.
>

The number of words something takes to standardize something is not a=20
useful measure of its complexity. Not to the user. After all, most users=20
don't read the standard.

What makes something complex to the user is that it does not fit the user's=
=20
*expectations*. People who are used to English and most European languages=
=20
read left-to-right, top-to-bottom. As such, their expectations will be that=
=20
compilers do things left-to-right, top-to-bottom.

A language becomes complex when it does not fit users' expectations. When=
=20
that happens, you have to look up esoteric rules about how the language=20
actually behaves. And then you have to later remember those rules when you=
=20
write code.

For example, let's say that you switched the meaning of the `for` and `if`=
=20
keywords. Not today, but way back in the days of C when those keywords were=
=20
first designed. It would not make the standard one iota more complex. But=
=20
it would make *understanding* the language more complex, because you would=
=20
have conditional statements that use `for` and looping constructs that use=
=20
`if`. The keywords clearly are wrong here, which requires that the user=20
cannot intuit their way through the language. They must learn it by route.=
=20
That's more complex.

That kind of understanding is the complexity we're trying to reduce here.=
=20
If we make the language behave the way people expect it to, then the=20
language becomes simpler to use.

Point 1 above is wrong.  A change that specifies behavior formerly=20
>> unspecified cannot be breaking.  Implementations that have made promises=
=20
>> beyond what the standard offers can be broken, but that is not the probl=
em=20
>> of the committee.  Programmers who relied on their implementation's orde=
r=20
>> are, as per Point 4 above, to be scorned.
>>
>> This *is *a breaking change *to implementations*. Even if the=20
> implementation did not promise anything beyond the standard to the user,=
=20
> the conforming status could be broken in the sense of new stricter rules=
=20
> silently, because not all currently conforming implementations obey the n=
ew=20
> rules. Thus, *it is forcing potentially more work on current=20
> implementations*. It would make problems not existed before.
>

.... so how is that any different from *every other change to the standard*?=
=20
Every change is a "breaking change to implementations". Every change causes=
=20
"potentially more work on current implementations".

That's just how it is. That implementations may need to change with the=20
standard is a statement that is so obvious that pointing it out means=20
nothing.

The term "breaking change" doesn't mean whatever you want it to mean. It=20
has a very clear and specific meaning in the context of standards: a change=
=20
to a standard where something that had functional behavior before the=20
change no longer is functional (hence the word "breaking").

There is no code which had well-defined behavior before that will no longer=
=20
have well-defined behavior after this change. Therefore, this is not a=20
breaking change.
=20

> Point 4 above places the cart squarely in front of the horse.  The reason=
=20
>> programmers have so much trouble with the existing rules is that the=20
>> existing rules are stupid.=20
>>
>
> I don't find it reasonable. These programmers would have more=20
> trouble.because new rules are more specific and complicated. And I am sur=
e=20
> who have no trouble before could have trouble since they need more effort=
=20
> to keep there original intent on the code.
>

Other languages provide strict guarantees about the order of evaluation of=
=20
expressions. Yet new programmers don't find these rules to be "more=20
specific and complicated".
=20

> The way to fix the situation is to fix the stupid rules, not to treat the=
m=20
>> as a *pons asinorum* so that smug superiority can be asserted.  The code=
=20
>> would not be bad if the language had correct rules.
>>
>> There is no need and no way to "fix" at all. Whatever you proposed to=20
> change, the change itself makes it more difficult to learn, because old=
=20
> rules are still technically correct and would be with contemporary=20
> implementation for a long time.
>

But then... they won't be.

I'm not sure I understand your point here. You seem to be saying that,=20
because it'll make things complicated during a transitional period, we=20
shouldn't transition at all.

Nonsense. We should design for the future, not for the past. And in the=20
future, when most compilers have been upgraded to the new standard, we=20
simply won't have to care about the old rules anymore.

The way to fix the problem is to *fix it*. Even if it's painful for a=20
while, so long as the pain is limited and the destination is far less=20
painful, it is worth doing.

How can newbies ignore the old rules?
>

Very easily; nobody tells them about it.
=20

> How do they figure out whether there are bugs in the old code with the=20
> change of the rules?
>

How would a "newbie" to C++ see such bugs *today*, with the current rules?=
=20
They wouldn't, because most newbies basically assume that the compiler=20
evaluates expressions the way they're written. And we *know* they assume=20
this because newbies are *far more likely* to write code that depends on=20
such evaluations than experienced C++ programmers.

So the usual way this plays out is that the "newbie" writes bad code, then=
=20
either an experienced C++ programmer sees it or a static analysis tool=20
detects it.

See, newbies don't fix these bugs; they *introduce* them. They're going to=
=20
write that code one way or another. By specifying the evaluation order, we=
=20
make it so that their code isn't a bug.

That's a win in my book.
=20

> Or how do they avoid old code totally? For a language like C++, no way,=
=20
> practically. They would eventually require to learn the old rules, plus t=
he=20
> new one. That is, you'd actually build another *pons asinorum*, and harm=
=20
> every sane users. The change itself is more stupid than any choice of the=
=20
> rules.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

On Sunday, December 6, 2015 at 3:43:14 AM UTC-5, FrankHB1989 wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Sorry for occasional =
deletion of the original post ...<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=88=
5=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=8812:56:15=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">P0145R0 is bad for two reasons.=C2=A0 First, it (del=
iberately) does not specify a fixed order of evaluation for all expressions=
 (thereby failing to solve the problem it ostensibly addresses), and second=
, it does not specify that the order should always be strictly left-to-righ=
t (thereby failing to provide a rule which is simple to understand). =C2=A0=
(Point 2 above is thus a consequence.)<br><br></div></blockquote><div>This =
is not totally consequence of the design of the rules or=20
approach of the wording. The root reason is &quot;left-to-right&quot; is=20
essentially and naturally more complicated than &quot;unsequenced&quot; (yo=
u&#39;d=20
define what is &quot;left&quot; and what is &quot;right&quot;). And you can=
&#39;t remove=20
&quot;unsequenced&quot; rules away at all, because there are other use of t=
hem. So
 the result is, you need more words to clarify it, always more wordy.<br></=
div></div></blockquote><div><br>The number of words something takes to stan=
dardize something is not a useful measure of its complexity. Not to the use=
r. After all, most users don&#39;t read the standard.<br><br>What makes som=
ething complex to the user is that it does not fit the user&#39;s <i>expect=
ations</i>. People who are used to English and most European languages read=
 left-to-right, top-to-bottom. As such, their expectations will be that com=
pilers do things left-to-right, top-to-bottom.<br><br>A language becomes co=
mplex when it does not fit users&#39; expectations. When that happens, you =
have to look up esoteric rules about how the language actually behaves. And=
 then you have to later remember those rules when you write code.<br><br>Fo=
r example, let&#39;s say that you switched the meaning of the `for` and `if=
` keywords. Not today, but way back in the days of C when those keywords we=
re first designed. It would not make the standard one iota more complex. Bu=
t it would make <i>understanding</i> the language more complex, because you=
 would have conditional statements that use `for` and looping constructs th=
at use `if`. The keywords clearly are wrong here, which requires that the u=
ser cannot intuit their way through the language. They must learn it by rou=
te. That&#39;s more complex.<br><br>That kind of understanding is the compl=
exity we&#39;re trying to reduce here. If we make the language behave the w=
ay people expect it to, then the language becomes simpler to use.<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></di=
v><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">Point 1 above is=
 wrong.=C2=A0 A change that specifies behavior formerly unspecified cannot =
be breaking.=C2=A0 Implementations that have made promises beyond what the =
standard offers can be broken, but that is not the problem of the committee=
..=C2=A0 Programmers who relied on their implementation&#39;s order are, as =
per Point 4 above, to be scorned.<br><div><br></div></div></blockquote><div=
>This <i>is </i>a breaking change <b>to implementations</b>. Even if=20
the implementation did not promise anything beyond the standard to the=20
user, the conforming status could be broken in the sense of new stricter
 rules silently, because not all currently conforming implementations=20
obey the new rules. Thus, <b>it is forcing potentially more work on current=
 implementations</b>. It would make problems not existed before.</div></div=
></blockquote><div><br>... so how is that any different from <i>every other=
 change to the standard</i>? Every change is a &quot;breaking change to imp=
lementations&quot;. Every change causes &quot;potentially more work on curr=
ent implementations&quot;.<br><br>That&#39;s just how it is. That implement=
ations may need to change with the standard is a statement that is so obvio=
us that pointing it out means nothing.<br><br>The term &quot;breaking chang=
e&quot; doesn&#39;t mean whatever you want it to mean. It has a very clear =
and specific meaning in the context of standards: a change to a standard wh=
ere something that had functional behavior before the change no longer is f=
unctional (hence the word &quot;breaking&quot;).<br><br>There is no code wh=
ich had well-defined behavior before that will no longer have well-defined =
behavior after this change. Therefore, this is not a breaking change.<br>=
=C2=A0</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"><div dir=3D"ltr"><div></=
div><div>Point 4 above places the cart squarely in front of the horse.=C2=
=A0 The reason programmers have so much trouble with the existing rules is =
that the existing rules are stupid. </div></div></blockquote><div><br>I don=
&#39;t find it reasonable. These programmers would have more trouble.becaus=
e new rules are more specific and complicated. And I am sure who have no tr=
ouble before could have trouble since they need more effort to keep there o=
riginal intent on the code.<br></div></div></blockquote><div><br>Other lang=
uages provide strict guarantees about the order of evaluation of expression=
s. Yet new programmers don&#39;t find these rules to be &quot;more specific=
 and complicated&quot;.<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><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>The way to fix the situation is to fix the stupid r=
ules, not to treat them as a <i>pons asinorum</i>=C2=A0so that smug superio=
rity can be asserted.=C2=A0 The code would not be bad if the language had c=
orrect rules.<br><br></div></div></blockquote><div>There is no need and no =
way to &quot;fix&quot; at all. Whatever you proposed to change, the change =
itself makes it more difficult to learn, because old rules are still techni=
cally correct and would be with contemporary implementation for a long time=
..</div></div></blockquote><div><br>But then... they won&#39;t be.<br><br>I&=
#39;m not sure I understand your point here. You seem to be saying that, be=
cause it&#39;ll make things complicated during a transitional period, we sh=
ouldn&#39;t transition at all.<br><br>Nonsense. We should design for the fu=
ture, not for the past. And in the future, when most compilers have been up=
graded to the new standard, we simply won&#39;t have to care about the old =
rules anymore.<br><br>The way to fix the problem is to <i>fix it</i>. Even =
if it&#39;s painful for a while, so long as the pain is limited and the des=
tination is far less painful, it is worth doing.<br><br></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> How can newbies igno=
re the old rules?</div></div></blockquote><div><br>Very easily; nobody tell=
s them about it.<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>How do they figure out whether there are bugs in th=
e old code with the change of the rules?</div></div></blockquote><div><br>H=
ow would a &quot;newbie&quot; to C++ see such bugs <i>today</i>, with the c=
urrent rules? They wouldn&#39;t, because most newbies basically assume that=
 the compiler evaluates expressions the way they&#39;re written. And we <i>=
know</i> they assume this because newbies are <i>far more likely</i> to wri=
te code that depends on such evaluations than experienced C++ programmers.<=
br><br>So the usual way this plays out is that the &quot;newbie&quot; write=
s bad code, then either an experienced C++ programmer sees it or a static a=
nalysis tool detects it.<br><br>See, newbies don&#39;t fix these bugs; they=
 <i>introduce</i> them. They&#39;re going to write that code one way or ano=
ther. By specifying the evaluation order, we make it so that their code isn=
&#39;t a bug.<br><br>That&#39;s a win in my book.<br>=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"><div>Or how do they avo=
id old code totally? For a language like C++, no way, practically. They wou=
ld eventually require to learn the old rules, plus the new one. That is, yo=
u&#39;d actually build another <i>pons asinorum</i>, and harm every sane us=
ers. The change itself is more stupid than any choice of the rules.<br></di=
v></div></blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_112_1012955533.1449416823996--
------=_Part_111_423252750.1449416823996--

.

------=_Part_70_41351239.1449456768899
Content-Type: multipart/alternative;
 boundary="----=_Part_71_1876623923.1449456768905"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC=
+8=E4=B8=8B=E5=8D=8811:47:04=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Sunday, December 6, 2015 at 3:43:14 AM UTC-5, FrankHB1989 wrote:
>>
>> Sorry for occasional deletion of the original post ...
>>
>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD =
UTC+8=E4=B8=8A=E5=8D=8812:56:15=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> P0145R0 is bad for two reasons.  First, it (deliberately) does not=20
>>> specify a fixed order of evaluation for all expressions (thereby failin=
g to=20
>>> solve the problem it ostensibly addresses), and second, it does not spe=
cify=20
>>> that the order should always be strictly left-to-right (thereby failing=
 to=20
>>> provide a rule which is simple to understand).  (Point 2 above is thus =
a=20
>>> consequence.)
>>>
>>> This is not totally consequence of the design of the rules or approach=
=20
>> of the wording. The root reason is "left-to-right" is essentially and=20
>> naturally more complicated than "unsequenced" (you'd define what is "lef=
t"=20
>> and what is "right"). And you can't remove "unsequenced" rules away at a=
ll,=20
>> because there are other use of them. So the result is, you need more wor=
ds=20
>> to clarify it, always more wordy.
>>
>
> The number of words something takes to standardize something is not a=20
> useful measure of its complexity. Not to the user. After all, most users=
=20
> don't read the standard.
>
> For this case, it is more or less related.

Since "left-to-right" rules are not easy to be describe neatly and=20
precisely (in spite of its difficulty of learning), a serious book teaching=
=20
the  language might have to reference the rules quite literally. So words=
=20
count.
=20

> What makes something complex to the user is that it does not fit the=20
> user's *expectations*. People who are used to English and most European=
=20
> languages read left-to-right, top-to-bottom. As such, their expectations=
=20
> will be that compilers do things left-to-right, top-to-bottom.
>
> For "easy" things, there are several reasons against this.

   - This is false if users' expectations differ significantly. There are=
=20
   no such single expectations for everyone. *Hiding the fact makes things=
=20
   more difficult.* So better keep it as-is.
   - As a language with built-in side effects support, evaluation order=20
   matters. *Fine-grained rules to specify order are needed.* Explicit=20
   order is one only one special case of it. This is not the case of "Engli=
sh=20
   and most European languages". If the users are confused, they should lea=
rn=20
   why they are not the same, not *be lazy*.
   - *Habits are not addicts.* If "left-to-right, top-to-bottom" is not=20
   always true *by need* other than "users know that" at first, it should=
=20
   be abandoned.
   - Any serious language should not simply copy the pseudo "rules" from=20
   the natural languages *by design*, because it is indeed more complicated=
=20
   than natural languages in nature. Yes, I am saying all natural languages=
=20
   are not serious in this sense, because they essentially have *no design*=
..=20
   The evolution of the "rules" (if any) of natural languages is not ruled =
by=20
   the immediate and explicit need of users, *by intention*.
   - *Evaluation strategy is the very basic knowledge to learn any=20
   programming languages.* The order of evaluation is one aspect in it,=20
   even this may be not so important if a language provides only pure=20
   computation on evaluation. Anyway, this is not the case of here. C++ is =
not=20
   so-called "purely functional" language at all. You can't tell users the=
=20
   story about parameters passing in English and most European languages,=
=20
   either. Users would meet the whole problems (explicit rules different to=
=20
   any natural language) sooner or later. For a language would often used=
=20
   seriously, *sooner is better*.
  =20

And for the order of reading... Why the name lookup in class scope=20
*sometimes* not "top-to-bottom"?
=20

> A language becomes complex when it does not fit users' expectations. When=
=20
> that happens, you have to look up esoteric rules about how the language=
=20
> actually behaves. And then you have to later remember those rules when yo=
u=20
> write code.
>
> No, I don't. I am not a language lawyer (e.g. as Richard Smith :). I=20
generally do not to keep rules in mind. I keep the index. When in doubt, I=
=20
know how to figure out what it should be. (And in fact I think most wording=
=20
are too verbose and not worth remembering.) The only exception is 12.8=20
"when certain criteria are met..." because too many people have asked me=20
why compilers swallow the calls of copy constructors. Ironically, this rule=
=20
is far more subtle than any single rule of evaluation order, almost only=20
fit for C++, and almost have bitten me *at first* glance (*the evaluation=
=20
rules did not*). But it is still necessary for the design goal and=20
usefulness of C++, so they should not be removed. So why deliberately=20
remove another useful rule?
=20

> For example, let's say that you switched the meaning of the `for` and `if=
`=20
> keywords. Not today, but way back in the days of C when those keywords we=
re=20
> first designed. It would not make the standard one iota more complex. But=
=20
> it would make *understanding* the language more complex, because you=20
> would have conditional statements that use `for` and looping constructs=
=20
> that use `if`. The keywords clearly are wrong here, which requires that t=
he=20
> user cannot intuit their way through the language. They must learn it by=
=20
> route. That's more complex.
>
> That kind of understanding is the complexity we're trying to reduce here.=
=20
> If we make the language behave the way people expect it to, then the=20
> language becomes simpler to use.
>
>  The historical reasons date back to the early age of programming=20
languages, earlier than C, i.e. since FORTRAN and ALGOL. Yes, there are=20
some problems. But they are significantly different than the rules you want=
=20
to remove here. Even the understanding problems are more or less similar=20
for newbies, they should not for skilled users. The redundancy between "if"=
=20
and "for" (or even the ability of recursive calls which original FORTRAN=20
lacks of), is *accidental*. And it is just *redundant*. Both points are not=
=20
applicable for the unsequenced evaluation rules. The "unsequenced" is more=
=20
natural than "left-to-right" or any hard-coded additional rules if you=20
simply not specified it, at least for evaluations between arguments of a=20
function.

The legacy can have been thrown away, if you want. For example, Scheme does=
=20
not have built-in loop. It forces the implementation to provide tail call=
=20
optimization. Any former "keywords" dedicated for loop constructs can be=20
thus implement trivially as libraries.
=20

> Point 1 above is wrong.  A change that specifies behavior formerly=20
>>> unspecified cannot be breaking.  Implementations that have made promise=
s=20
>>> beyond what the standard offers can be broken, but that is not the prob=
lem=20
>>> of the committee.  Programmers who relied on their implementation's ord=
er=20
>>> are, as per Point 4 above, to be scorned.
>>>
>>> This *is *a breaking change *to implementations*. Even if the=20
>> implementation did not promise anything beyond the standard to the user,=
=20
>> the conforming status could be broken in the sense of new stricter rules=
=20
>> silently, because not all currently conforming implementations obey the =
new=20
>> rules. Thus, *it is forcing potentially more work on current=20
>> implementations*. It would make problems not existed before.
>>
>
> ... so how is that any different from *every other change to the standard=
*?=20
> Every change is a "breaking change to implementations". Every change caus=
es=20
> "potentially more work on current implementations".
>
> Other changes generally benefit. These changes are worthy. Not this one.
=20

> That's just how it is. That implementations may need to change with the=
=20
> standard is a statement that is so obvious that pointing it out means=20
> nothing.
>
> Obviously.
=20

> The term "breaking change" doesn't mean whatever you want it to mean. It=
=20
> has a very clear and specific meaning in the context of standards: a chan=
ge=20
> to a standard where something that had functional behavior before the=20
> change no longer is functional (hence the word "breaking").
>
Please tell me where does the standard specify the meaning of "breaking=20
change". I know there is annex C, which is informative and have nothing to=
=20
do with "breaking" formally, even it would be the focus.


> There is no code which had well-defined behavior before that will no=20
> longer have well-defined behavior after this change. Therefore, this is n=
ot=20
> a breaking change.
>

I admit this is not a breaking change on conformance of C++ code. But it=20
force the implementation to change. The "breaking" here is just stricter=20
than you talked about. In this sense there are still changes not breaking,=
=20
e.g. fix of editorial issues.

And now I should emphasize that, this is also breaking for user code since=
=20
the meaning of the program would be altered, even not so many people know=
=20
what is going on. Please analyze the code formally. *I am saying the C++=20
code is being breaking when the rules are changed, not the programs=20
(behavior at end-users' view).*=20

> =20
>
>> Point 4 above places the cart squarely in front of the horse.  The reaso=
n=20
>>> programmers have so much trouble with the existing rules is that the=20
>>> existing rules are stupid.=20
>>>
>>
>> I don't find it reasonable. These programmers would have more=20
>> trouble.because new rules are more specific and complicated. And I am su=
re=20
>> who have no trouble before could have trouble since they need more effor=
t=20
>> to keep there original intent on the code.
>>
>
> Other languages provide strict guarantees about the order of evaluation o=
f=20
> expressions. Yet new programmers don't find these rules to be "more=20
> specific and complicated".
> =20
>
Not all. Scheme has still mandate the order of evaluations in=20
subexpressions of function application "unspecified".

Hard-coded additional rules do not make it easy to use once the users are=
=20
not ignorant to this. They are redundant to skilled users. *Why you insist=
=20
to keep newbie-friendly but not for others?*
=20

> The way to fix the situation is to fix the stupid rules, not to treat the=
m=20
>>> as a *pons asinorum* so that smug superiority can be asserted.  The=20
>>> code would not be bad if the language had correct rules.
>>>
>>> There is no need and no way to "fix" at all. Whatever you proposed to=
=20
>> change, the change itself makes it more difficult to learn, because old=
=20
>> rules are still technically correct and would be with contemporary=20
>> implementation for a long time.
>>
>
> But then... they won't be.
>

They would. Even now there a a lot of companies use very old implementation=
=20
as I have known, e.g. Baidu use GCC 3.x in their production environment.=20
(And in my experience, G++ does not force the proposed rules.) Not many=20
people can safely believe the rules are effective at work. This will not=20
change before it (in C++2x?) widely implemented and used.
=20

>
> I'm not sure I understand your point here. You seem to be saying that,=20
> because it'll make things complicated during a transitional period, we=20
> shouldn't transition at all.
> =20
>
Nonsense. We should design for the future, not for the past. And in the=20
> future, when most compilers have been upgraded to the new standard, we=20
> simply won't have to care about the old rules anymore.
>
> You should change if it is a fix of former defects or there are new=20
features worthy. But please don't introduce changes bad in general (e.g.=20
dynamic exception specification), or changes can't work in reality for a=20
long time (e.g. 'export', though it is also somewhat "bad"). The change=20
here seem to be fit in both sets: bad, and not working in near future.
=20

> The way to fix the problem is to *fix it*. Even if it's painful for a=20
> while, so long as the pain is limited and the destination is far less=20
> painful, it is worth doing.
>
> This is not a (right) problem at very first. The "fix" is also wrong for=
=20
its intention. The pain is in vain. So it is not worth doing.
=20

> How can newbies ignore the old rules?
>>
>
> Very easily; nobody tells them about it.
> =20
>
They would be in pain again when they bit by UB with old implementations.=
=20
Please evaluate the probability seriously.
=20

> How do they figure out whether there are bugs in the old code with the=20
>> change of the rules?
>>
>
> How would a "newbie" to C++ see such bugs *today*, with the current=20
> rules? They wouldn't, because most newbies basically assume that the=20
> compiler evaluates expressions the way they're written. And we *know*=20
> they assume this because newbies are *far more likely* to write code that=
=20
> depends on such evaluations than experienced C++ programmers.
>
> You must be kidding. Do newbies have rights to deny the actual behavior o=
f=20
programs they wrote?
=20

> So the usual way this plays out is that the "newbie" writes bad code, the=
n=20
> either an experienced C++ programmer sees it or a static analysis tool=20
> detects it.
>
> This is even more fancy. Currently, features like [-Wsequenced] is=20
encouraged by the existence of current rules. How will programmers adopt=20
such features if the standard do not force them? Trust me, not so many=20
"experienced" programmers bother to do so.
=20

> See, newbies don't fix these bugs; they *introduce* them. They're going=
=20
> to write that code one way or another. By specifying the evaluation order=
,=20
> we make it so that their code isn't a bug.
>
> That sounds like we are encouraging *craps *to be produced.

If a program is with crappy bugs, I don't think there there is much worth=
=20
keeping it anymore, because these bugs are so naive and I can't simply=20
trust it is otherwise somewhat bug-free. It should either be throughout=20
checked and fixed, or be rewritten by programmers who would not produce=20
such bugs.
=20

> That's a win in my book.
> =20
>
Which one?=20

> Or how do they avoid old code totally? For a language like C++, no way,=
=20
>> practically. They would eventually require to learn the old rules, plus =
the=20
>> new one. That is, you'd actually build another *pons asinorum*, and harm=
=20
>> every sane users. The change itself is more stupid than any choice of th=
e=20
>> rules.
>>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E6=
=97=A5 UTC+8=E4=B8=8B=E5=8D=8811:47:04=EF=BC=8CNicol Bolas=E5=86=99=E9=81=
=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sunday, Decembe=
r 6, 2015 at 3:43:14 AM UTC-5, FrankHB1989 wrote:<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">Sorry for occasional deletion of the origina=
l post ...<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=
=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=8812:56:15=EF=BC=8CHyman Rosen=E5=86=
=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">P0145R0 is bad for two reasons.=C2=A0 First, it (deliberately) does not =
specify a fixed order of evaluation for all expressions (thereby failing to=
 solve the problem it ostensibly addresses), and second, it does not specif=
y that the order should always be strictly left-to-right (thereby failing t=
o provide a rule which is simple to understand). =C2=A0(Point 2 above is th=
us a consequence.)<br><br></div></blockquote><div>This is not totally conse=
quence of the design of the rules or=20
approach of the wording. The root reason is &quot;left-to-right&quot; is=20
essentially and naturally more complicated than &quot;unsequenced&quot; (yo=
u&#39;d=20
define what is &quot;left&quot; and what is &quot;right&quot;). And you can=
&#39;t remove=20
&quot;unsequenced&quot; rules away at all, because there are other use of t=
hem. So
 the result is, you need more words to clarify it, always more wordy.<br></=
div></div></blockquote><div><br>The number of words something takes to stan=
dardize something is not a useful measure of its complexity. Not to the use=
r. After all, most users don&#39;t read the standard.<br><br></div></blockq=
uote><div>For this case, it is more or less related.<br><br>Since &quot;lef=
t-to-right&quot; rules are not easy to be describe neatly and precisely (in=
 spite of its difficulty of learning), a serious book teaching the=C2=A0 la=
nguage might have to reference the rules quite literally. So words count.<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>What ma=
kes something complex to the user is that it does not fit the user&#39;s <i=
>expectations</i>. People who are used to English and most European languag=
es read left-to-right, top-to-bottom. As such, their expectations will be t=
hat compilers do things left-to-right, top-to-bottom.<br><br></div></blockq=
uote><div>For &quot;easy&quot; things, there are several reasons against th=
is.<br><ul><li>This is false if users&#39; expectations differ significantl=
y. There are no such single expectations for everyone. <b>Hiding the fact m=
akes things more difficult.</b> So better keep it as-is.</li><li>As a langu=
age with built-in side effects support, evaluation order matters. <b>Fine-g=
rained rules to specify order are needed.</b> Explicit order is one only on=
e special case of it. This is not the case of &quot;English and most Europe=
an languages&quot;. If the users are confused, they should learn why they a=
re not the same, not <i>be lazy</i>.</li><li><b>Habits are not addicts.</b>=
 If &quot;left-to-right, top-to-bottom&quot; is not always true <i>by need<=
/i> other than &quot;users know that&quot; at first, it should be abandoned=
..<br></li><li>Any serious language should not simply copy the pseudo &quot;=
rules&quot; from the natural languages <i>by design</i>,
 because it is indeed more complicated than natural languages in nature.
 Yes, I am saying all natural languages are not serious in this sense,=20
because they essentially have <i>no design</i>. The evolution of the &quot;=
rules&quot; (if any) of natural languages is not ruled by the immediate and=
 explicit need of users, <i>by intention</i>.</li><li><b>Evaluation strateg=
y is the very basic knowledge to learn any programming languages.</b> The o=
rder of evaluation is one aspect in it, even this may be not so important i=
f a language provides only pure computation on evaluation. Anyway, this is =
not the case of here. C++ is not so-called &quot;purely functional&quot; la=
nguage at all. You can&#39;t tell users the story about parameters passing =
in English and most European languages, either. Users would meet the whole =
problems (explicit rules different to any natural language) sooner or later=
.. For a language would often used seriously, <b>sooner is better</b>.<br></=
li></ul></div><div><br>And for the order of reading... Why the name lookup =
in class scope <i>sometimes</i> not &quot;top-to-bottom&quot;?<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>A language becomes=
 complex when it does not fit users&#39; expectations. When that happens, y=
ou have to look up esoteric rules about how the language actually behaves. =
And then you have to later remember those rules when you write code.<br><br=
></div></blockquote><div>No, I don&#39;t. I am not a language lawyer (e.g. =
as Richard Smith :). I generally do not to keep rules in mind. I keep the i=
ndex. When in doubt, I know how to figure out what it should be. (And in fa=
ct I think most wording are too verbose and not worth remembering.) The onl=
y exception is 12.8 &quot;when certain criteria are met...&quot; because to=
o many people have asked me why compilers swallow the calls of copy constru=
ctors. Ironically, this rule is far more subtle than any single rule of eva=
luation order, almost only fit for C++, and almost have bitten me <b>at fir=
st</b> glance (<b>the evaluation rules did not</b>). But it is still necess=
ary for the design goal and usefulness of C++, so they should not be remove=
d. So why deliberately remove another useful rule?<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>For example, let&#39;s say tha=
t you switched the meaning of the `for` and `if` keywords. Not today, but w=
ay back in the days of C when those keywords were first designed. It would =
not make the standard one iota more complex. But it would make <i>understan=
ding</i> the language more complex, because you would have conditional stat=
ements that use `for` and looping constructs that use `if`. The keywords cl=
early are wrong here, which requires that the user cannot intuit their way =
through the language. They must learn it by route. That&#39;s more complex.=
<br><br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v>That kind of understanding is the complexity we&#39;re trying to reduce h=
ere. If we make the language behave the way people expect it to, then the l=
anguage becomes simpler to use.<br><br></div></blockquote><div>=C2=A0The hi=
storical reasons date back to the early age of programming=20
languages, earlier than C, i.e. since FORTRAN and ALGOL. Yes, there are=20
some problems. But they are significantly different than the rules you want=
 to remove here. Even the understanding problems are more or less similar f=
or newbies, they should not for skilled users. The redundancy between &quot=
;if&quot; and &quot;for&quot; (or even the ability of recursive calls which=
 original FORTRAN lacks of), is <i>accidental</i>. And it is just <i>redund=
ant</i>. Both points are not applicable for the unsequenced evaluation rule=
s. The &quot;unsequenced&quot; is more natural than &quot;left-to-right&quo=
t; or any hard-coded additional rules if you simply not specified it, at le=
ast for evaluations between arguments of a function.<b></b><br><br>The lega=
cy can have been thrown away, if you want. For=20
example, Scheme does not have built-in loop. It forces the=20
implementation to provide tail call optimization. Any former &quot;keywords=
&quot; dedicated
 for loop constructs can be thus implement trivially as libraries.<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><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"><div dir=3D"ltr">Point 1 above is wrong.=C2=A0 A=
 change that specifies behavior formerly unspecified cannot be breaking.=C2=
=A0 Implementations that have made promises beyond what the standard offers=
 can be broken, but that is not the problem of the committee.=C2=A0 Program=
mers who relied on their implementation&#39;s order are, as per Point 4 abo=
ve, to be scorned.<br><div><br></div></div></blockquote><div>This <i>is </i=
>a breaking change <b>to implementations</b>. Even if=20
the implementation did not promise anything beyond the standard to the=20
user, the conforming status could be broken in the sense of new stricter
 rules silently, because not all currently conforming implementations=20
obey the new rules. Thus, <b>it is forcing potentially more work on current=
 implementations</b>. It would make problems not existed before.</div></div=
></blockquote><div><br>... so how is that any different from <i>every other=
 change to the standard</i>? Every change is a &quot;breaking change to imp=
lementations&quot;. Every change causes &quot;potentially more work on curr=
ent implementations&quot;.<br><br></div></blockquote><div>Other changes gen=
erally benefit. These changes are worthy. Not this one.<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>That&#39;s just how it is=
.. That implementations may need to change with the standard is a statement =
that is so obvious that pointing it out means nothing.<br><br></div></block=
quote><div>Obviously.<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>The term &quot;breaking change&quot; doesn&#39;t mean whate=
ver you want it to mean. It has a very clear and specific meaning in the co=
ntext of standards: a change to a standard where something that had functio=
nal behavior before the change no longer is functional (hence the word &quo=
t;breaking&quot;).<br></div></blockquote><div>Please tell me where does the=
 standard specify the meaning of &quot;breaking change&quot;. I know there =
is annex C, which is informative and have nothing to do with &quot;breaking=
&quot; formally, even it would be the focus.<b></b><br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div><br>There is no code which had well=
-defined behavior before that will no longer have well-defined behavior aft=
er this change. Therefore, this is not a breaking change.<br></div></blockq=
uote><div><br>I admit this is not a breaking change on conformance of C++ c=
ode. But it
 force the implementation to change. The &quot;breaking&quot; here is just=
=20
stricter than you talked about. In this sense there are still changes=20
not breaking, e.g. fix of editorial issues.<br><br>And now I should=20
emphasize that, this is also breaking for user code since the meaning of
 the program would be altered, even not so many people know what is=20
going on. Please analyze the code formally. <b>I am saying the C++ code is =
being breaking when the rules are changed, not the programs (behavior at en=
d-users&#39; view).</b> <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><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"><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></div><div>Point 4 above places the cart squarely in front of the horse=
..=C2=A0 The reason programmers have so much trouble with the existing rules=
 is that the existing rules are stupid. </div></div></blockquote><div><br>I=
 don&#39;t find it reasonable. These programmers would have more trouble.be=
cause new rules are more specific and complicated. And I am sure who have n=
o trouble before could have trouble since they need more effort to keep the=
re original intent on the code.<br></div></div></blockquote><div><br>Other =
languages provide strict guarantees about the order of evaluation of expres=
sions. Yet new programmers don&#39;t find these rules to be &quot;more spec=
ific and complicated&quot;.<br>=C2=A0</div></blockquote><div>Not all. Schem=
e has still mandate the order of evaluations in subexpressions of function =
application &quot;unspecified&quot;.<br><br>Hard-coded additional rules do =
not make it easy to use once the users=20
are not ignorant to this. They are redundant to skilled users. <b>Why you i=
nsist to keep newbie-friendly but not for others?</b><br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><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"><di=
v dir=3D"ltr"><div>The way to fix the situation is to fix the stupid rules,=
 not to treat them as a <i>pons asinorum</i>=C2=A0so that smug superiority =
can be asserted.=C2=A0 The code would not be bad if the language had correc=
t rules.<br><br></div></div></blockquote><div>There is no need and no way t=
o &quot;fix&quot; at all. Whatever you proposed to change, the change itsel=
f makes it more difficult to learn, because old rules are still technically=
 correct and would be with contemporary implementation for a long time.</di=
v></div></blockquote><div><br>But then... they won&#39;t be.<br></div></blo=
ckquote><div><br>They would. Even now there a a lot of companies use very o=
ld implementation as I have known, e.g. Baidu use GCC 3.x in their producti=
on environment. (And in my experience, G++ does not force the proposed rule=
s.) Not many people can safely believe the rules are effective at work. Thi=
s will not change before it (in C++2x?) widely implemented and used.<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><br>I&#39;m =
not sure I understand your point here. You seem to be saying that, because =
it&#39;ll make things complicated during a transitional period, we shouldn&=
#39;t transition at all.<br>=C2=A0</div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div>Nonsense. We should design for the future, not =
for the past. And in the future, when most compilers have been upgraded to =
the new standard, we simply won&#39;t have to care about the old rules anym=
ore.<br><br></div></blockquote><div>You should change if it is a fix of for=
mer defects or there are new=20
features worthy. But please don&#39;t introduce changes bad in general (e.g=
.. dynamic exception specification), or changes=20
can&#39;t work in reality for a long time (e.g. &#39;export&#39;, though it=
 is also somewhat &quot;bad&quot;). The change here seem to be fit in both =
sets: bad, and not working in near future.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>The way to fix the problem is to <i>fix it=
</i>. Even if it&#39;s painful for a while, so long as the pain is limited =
and the destination is far less painful, it is worth doing.<br><br></div></=
blockquote><div>This is not a (right) problem at very first. The &quot;fix&=
quot; is also wrong for its intention. The pain is in vain. So it is not wo=
rth doing.<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></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> H=
ow can newbies ignore the old rules?</div></div></blockquote><div><br>Very =
easily; nobody tells them about it.<br>=C2=A0</div></blockquote><div>They w=
ould be in pain again when they bit by UB with old implementations. Please =
evaluate the probability seriously.<br>=C2=A0<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><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>How do they figure out whether there are bugs in the old code=
 with the change of the rules?</div></div></blockquote><div><br>How would a=
 &quot;newbie&quot; to C++ see such bugs <i>today</i>, with the current rul=
es? They wouldn&#39;t, because most newbies basically assume that the compi=
ler evaluates expressions the way they&#39;re written. And we <i>know</i> t=
hey assume this because newbies are <i>far more likely</i> to write code th=
at depends on such evaluations than experienced C++ programmers.<br><br></d=
iv></blockquote><div>You must be kidding. Do newbies have rights to deny th=
e actual behavior of programs they wrote?<br>=C2=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div>So the usual way this plays out is that=
 the &quot;newbie&quot; writes bad code, then either an experienced C++ pro=
grammer sees it or a static analysis tool detects it.<br><br></div></blockq=
uote><div>This is even more fancy. Currently, features like [-Wsequenced] i=
s encouraged by the existence of current rules. How will programmers adopt =
such features if the standard do not force them? Trust me, not so many &quo=
t;experienced&quot; programmers bother to do so.<br>=C2=A0<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>See, newbies don&#39;t fix these=
 bugs; they <i>introduce</i> them. They&#39;re going to write that code one=
 way or another. By specifying the evaluation order, we make it so that the=
ir code isn&#39;t a bug.<br><br></div></blockquote><div>That sounds like we=
 are encouraging <i>craps </i>to be produced.<br><br>If a program is with c=
rappy bugs, I don&#39;t think there there is much worth keeping it anymore,=
 because these bugs are so naive and I can&#39;t simply trust it is otherwi=
se somewhat bug-free. It should either be throughout checked and fixed, or =
be rewritten by programmers who would not produce such bugs.<br>=C2=A0<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div>That&#39;s a win in =
my book.<br>=C2=A0</div></blockquote><div>Which one? <br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>Or how do they avoid old code totally? For a language l=
ike C++, no way, practically. They would eventually require to learn the ol=
d rules, plus the new one. That is, you&#39;d actually build another <i>pon=
s asinorum</i>, and harm every sane users. The change itself is more stupid=
 than any choice of the rules.<br></div></div></blockquote></blockquote><br=
>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_71_1876623923.1449456768905--
------=_Part_70_41351239.1449456768899--

.

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

Left-to-right order is simple to describe. For binary operators, the left
side is fully evaluated (i.e., all side effects are complete), the right
side is fully evaluated, then the operation is fully evaluated.  For
function calls, the function expression is fully evaluated, then each
parameter is fully initialized in left-to-right order by its corresponding
fully-evaluated argument expression, with each initialization complete
before the next one begins (so that an exception in argument evaluation
neatly destructs the previously initialized parameters).  And so forth.
You can go and look

The fundamental problem with unspecified order of evaluation is that people
write code that works as they expect because their implementation has the
same mental model that they do.  Then one day the implementation changes,
and all of a sudden the code doesn't work any more.  People, including
experts, have been having the same misunderstandings and making the same
errors for literally decades.  (For example, how long did it take to figure
out the f(new T, new T) issue?) The designers of Java and C# saw this as a
problem to be fixed and chose left-to-right order.  There is no good reason
for not doing the same in C++, but as I have seen (also for decades), there
are plenty of bad ones.

On Sun, Dec 6, 2015 at 9:52 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:

>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 U=
TC+8=E4=B8=8B=E5=8D=8811:47:04=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On Sunday, December 6, 2015 at 3:43:14 AM UTC-5, FrankHB1989 wrote:
>>>
>>> Sorry for occasional deletion of the original post ...
>>>
>>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD=
 UTC+8=E4=B8=8A=E5=8D=8812:56:15=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=
=BC=9A
>>>>
>>>> P0145R0 is bad for two reasons.  First, it (deliberately) does not
>>>> specify a fixed order of evaluation for all expressions (thereby faili=
ng to
>>>> solve the problem it ostensibly addresses), and second, it does not sp=
ecify
>>>> that the order should always be strictly left-to-right (thereby failin=
g to
>>>> provide a rule which is simple to understand).  (Point 2 above is thus=
 a
>>>> consequence.)
>>>>
>>>> This is not totally consequence of the design of the rules or approach
>>> of the wording. The root reason is "left-to-right" is essentially and
>>> naturally more complicated than "unsequenced" (you'd define what is "le=
ft"
>>> and what is "right"). And you can't remove "unsequenced" rules away at =
all,
>>> because there are other use of them. So the result is, you need more wo=
rds
>>> to clarify it, always more wordy.
>>>
>>
>> The number of words something takes to standardize something is not a
>> useful measure of its complexity. Not to the user. After all, most users
>> don't read the standard.
>>
>> For this case, it is more or less related.
>
> Since "left-to-right" rules are not easy to be describe neatly and
> precisely (in spite of its difficulty of learning), a serious book teachi=
ng
> the  language might have to reference the rules quite literally. So words
> count.
>
>
>> What makes something complex to the user is that it does not fit the
>> user's *expectations*. People who are used to English and most European
>> languages read left-to-right, top-to-bottom. As such, their expectations
>> will be that compilers do things left-to-right, top-to-bottom.
>>
>> For "easy" things, there are several reasons against this.
>
>    - This is false if users' expectations differ significantly. There are
>    no such single expectations for everyone. *Hiding the fact makes
>    things more difficult.* So better keep it as-is.
>    - As a language with built-in side effects support, evaluation order
>    matters. *Fine-grained rules to specify order are needed.* Explicit
>    order is one only one special case of it. This is not the case of "Eng=
lish
>    and most European languages". If the users are confused, they should l=
earn
>    why they are not the same, not *be lazy*.
>    - *Habits are not addicts.* If "left-to-right, top-to-bottom" is not
>    always true *by need* other than "users know that" at first, it should
>    be abandoned.
>    - Any serious language should not simply copy the pseudo "rules" from
>    the natural languages *by design*, because it is indeed more
>    complicated than natural languages in nature. Yes, I am saying all nat=
ural
>    languages are not serious in this sense, because they essentially have=
 *no
>    design*. The evolution of the "rules" (if any) of natural languages is
>    not ruled by the immediate and explicit need of users, *by intention*.
>    - *Evaluation strategy is the very basic knowledge to learn any
>    programming languages.* The order of evaluation is one aspect in it,
>    even this may be not so important if a language provides only pure
>    computation on evaluation. Anyway, this is not the case of here. C++ i=
s not
>    so-called "purely functional" language at all. You can't tell users th=
e
>    story about parameters passing in English and most European languages,
>    either. Users would meet the whole problems (explicit rules different =
to
>    any natural language) sooner or later. For a language would often used
>    seriously, *sooner is better*.
>
>
> And for the order of reading... Why the name lookup in class scope
> *sometimes* not "top-to-bottom"?
>
>
>> A language becomes complex when it does not fit users' expectations. Whe=
n
>> that happens, you have to look up esoteric rules about how the language
>> actually behaves. And then you have to later remember those rules when y=
ou
>> write code.
>>
>> No, I don't. I am not a language lawyer (e.g. as Richard Smith :). I
> generally do not to keep rules in mind. I keep the index. When in doubt, =
I
> know how to figure out what it should be. (And in fact I think most wordi=
ng
> are too verbose and not worth remembering.) The only exception is 12.8
> "when certain criteria are met..." because too many people have asked me
> why compilers swallow the calls of copy constructors. Ironically, this ru=
le
> is far more subtle than any single rule of evaluation order, almost only
> fit for C++, and almost have bitten me *at first* glance (*the evaluation
> rules did not*). But it is still necessary for the design goal and
> usefulness of C++, so they should not be removed. So why deliberately
> remove another useful rule?
>
>
>> For example, let's say that you switched the meaning of the `for` and
>> `if` keywords. Not today, but way back in the days of C when those keywo=
rds
>> were first designed. It would not make the standard one iota more comple=
x.
>> But it would make *understanding* the language more complex, because you
>> would have conditional statements that use `for` and looping constructs
>> that use `if`. The keywords clearly are wrong here, which requires that =
the
>> user cannot intuit their way through the language. They must learn it by
>> route. That's more complex.
>>
>> That kind of understanding is the complexity we're trying to reduce here=
..
>> If we make the language behave the way people expect it to, then the
>> language becomes simpler to use.
>>
>>  The historical reasons date back to the early age of programming
> languages, earlier than C, i.e. since FORTRAN and ALGOL. Yes, there are
> some problems. But they are significantly different than the rules you wa=
nt
> to remove here. Even the understanding problems are more or less similar
> for newbies, they should not for skilled users. The redundancy between "i=
f"
> and "for" (or even the ability of recursive calls which original FORTRAN
> lacks of), is *accidental*. And it is just *redundant*. Both points are
> not applicable for the unsequenced evaluation rules. The "unsequenced" is
> more natural than "left-to-right" or any hard-coded additional rules if y=
ou
> simply not specified it, at least for evaluations between arguments of a
> function.
>
> The legacy can have been thrown away, if you want. For example, Scheme
> does not have built-in loop. It forces the implementation to provide tail
> call optimization. Any former "keywords" dedicated for loop constructs ca=
n
> be thus implement trivially as libraries.
>
>
>> Point 1 above is wrong.  A change that specifies behavior formerly
>>>> unspecified cannot be breaking.  Implementations that have made promis=
es
>>>> beyond what the standard offers can be broken, but that is not the pro=
blem
>>>> of the committee.  Programmers who relied on their implementation's or=
der
>>>> are, as per Point 4 above, to be scorned.
>>>>
>>>> This *is *a breaking change *to implementations*. Even if the
>>> implementation did not promise anything beyond the standard to the user=
,
>>> the conforming status could be broken in the sense of new stricter rule=
s
>>> silently, because not all currently conforming implementations obey the=
 new
>>> rules. Thus, *it is forcing potentially more work on current
>>> implementations*. It would make problems not existed before.
>>>
>>
>> ... so how is that any different from *every other change to the
>> standard*? Every change is a "breaking change to implementations". Every
>> change causes "potentially more work on current implementations".
>>
>> Other changes generally benefit. These changes are worthy. Not this one.
>
>
>> That's just how it is. That implementations may need to change with the
>> standard is a statement that is so obvious that pointing it out means
>> nothing.
>>
>> Obviously.
>
>
>> The term "breaking change" doesn't mean whatever you want it to mean. It
>> has a very clear and specific meaning in the context of standards: a cha=
nge
>> to a standard where something that had functional behavior before the
>> change no longer is functional (hence the word "breaking").
>>
> Please tell me where does the standard specify the meaning of "breaking
> change". I know there is annex C, which is informative and have nothing t=
o
> do with "breaking" formally, even it would be the focus.
>
>
>> There is no code which had well-defined behavior before that will no
>> longer have well-defined behavior after this change. Therefore, this is =
not
>> a breaking change.
>>
>
> I admit this is not a breaking change on conformance of C++ code. But it
> force the implementation to change. The "breaking" here is just stricter
> than you talked about. In this sense there are still changes not breaking=
,
> e.g. fix of editorial issues.
>
> And now I should emphasize that, this is also breaking for user code sinc=
e
> the meaning of the program would be altered, even not so many people know
> what is going on. Please analyze the code formally. *I am saying the C++
> code is being breaking when the rules are changed, not the programs
> (behavior at end-users' view).*
>
>>
>>
>>> Point 4 above places the cart squarely in front of the horse.  The
>>>> reason programmers have so much trouble with the existing rules is tha=
t the
>>>> existing rules are stupid.
>>>>
>>>
>>> I don't find it reasonable. These programmers would have more
>>> trouble.because new rules are more specific and complicated. And I am s=
ure
>>> who have no trouble before could have trouble since they need more effo=
rt
>>> to keep there original intent on the code.
>>>
>>
>> Other languages provide strict guarantees about the order of evaluation
>> of expressions. Yet new programmers don't find these rules to be "more
>> specific and complicated".
>>
>>
> Not all. Scheme has still mandate the order of evaluations in
> subexpressions of function application "unspecified".
>
> Hard-coded additional rules do not make it easy to use once the users are
> not ignorant to this. They are redundant to skilled users. *Why you
> insist to keep newbie-friendly but not for others?*
>
>
>> The way to fix the situation is to fix the stupid rules, not to treat
>>>> them as a *pons asinorum* so that smug superiority can be asserted.
>>>> The code would not be bad if the language had correct rules.
>>>>
>>>> There is no need and no way to "fix" at all. Whatever you proposed to
>>> change, the change itself makes it more difficult to learn, because old
>>> rules are still technically correct and would be with contemporary
>>> implementation for a long time.
>>>
>>
>> But then... they won't be.
>>
>
> They would. Even now there a a lot of companies use very old
> implementation as I have known, e.g. Baidu use GCC 3.x in their productio=
n
> environment. (And in my experience, G++ does not force the proposed rules=
..)
> Not many people can safely believe the rules are effective at work. This
> will not change before it (in C++2x?) widely implemented and used.
>
>
>>
>> I'm not sure I understand your point here. You seem to be saying that,
>> because it'll make things complicated during a transitional period, we
>> shouldn't transition at all.
>>
>>
> Nonsense. We should design for the future, not for the past. And in the
>> future, when most compilers have been upgraded to the new standard, we
>> simply won't have to care about the old rules anymore.
>>
>> You should change if it is a fix of former defects or there are new
> features worthy. But please don't introduce changes bad in general (e.g.
> dynamic exception specification), or changes can't work in reality for a
> long time (e.g. 'export', though it is also somewhat "bad"). The change
> here seem to be fit in both sets: bad, and not working in near future.
>
>
>> The way to fix the problem is to *fix it*. Even if it's painful for a
>> while, so long as the pain is limited and the destination is far less
>> painful, it is worth doing.
>>
>> This is not a (right) problem at very first. The "fix" is also wrong for
> its intention. The pain is in vain. So it is not worth doing.
>
>
>> How can newbies ignore the old rules?
>>>
>>
>> Very easily; nobody tells them about it.
>>
>>
> They would be in pain again when they bit by UB with old implementations.
> Please evaluate the probability seriously.
>
>
>> How do they figure out whether there are bugs in the old code with the
>>> change of the rules?
>>>
>>
>> How would a "newbie" to C++ see such bugs *today*, with the current
>> rules? They wouldn't, because most newbies basically assume that the
>> compiler evaluates expressions the way they're written. And we *know*
>> they assume this because newbies are *far more likely* to write code
>> that depends on such evaluations than experienced C++ programmers.
>>
>> You must be kidding. Do newbies have rights to deny the actual behavior
> of programs they wrote?
>
>
>> So the usual way this plays out is that the "newbie" writes bad code,
>> then either an experienced C++ programmer sees it or a static analysis t=
ool
>> detects it.
>>
>> This is even more fancy. Currently, features like [-Wsequenced] is
> encouraged by the existence of current rules. How will programmers adopt
> such features if the standard do not force them? Trust me, not so many
> "experienced" programmers bother to do so.
>
>
>> See, newbies don't fix these bugs; they *introduce* them. They're going
>> to write that code one way or another. By specifying the evaluation orde=
r,
>> we make it so that their code isn't a bug.
>>
>> That sounds like we are encouraging *craps *to be produced.
>
> If a program is with crappy bugs, I don't think there there is much worth
> keeping it anymore, because these bugs are so naive and I can't simply
> trust it is otherwise somewhat bug-free. It should either be throughout
> checked and fixed, or be rewritten by programmers who would not produce
> such bugs.
>
>
>> That's a win in my book.
>>
>>
> Which one?
>
>> Or how do they avoid old code totally? For a language like C++, no way,
>>> practically. They would eventually require to learn the old rules, plus=
 the
>>> new one. That is, you'd actually build another *pons asinorum*, and
>>> harm every sane users. The change itself is more stupid than any choice=
 of
>>> the 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Left-to-right order is simple to describe. For binary oper=
ators, the left side is fully evaluated (i.e., all side effects are complet=
e), the right side is fully evaluated, then the operation is fully evaluate=
d.=C2=A0 For function calls, the function expression is fully evaluated, th=
en each parameter is fully initialized in left-to-right order by its corres=
ponding fully-evaluated argument expression, with each initialization compl=
ete before the next one begins (so that an exception in argument evaluation=
 neatly destructs the previously initialized parameters).=C2=A0 And so fort=
h.=C2=A0 You can go and look=C2=A0<br><br>The fundamental problem with unsp=
ecified order of evaluation is that people write code that works as they ex=
pect because their implementation has the same mental model that they do.=
=C2=A0 Then one day the implementation changes, and all of a sudden the cod=
e doesn&#39;t work any more.=C2=A0 People, including experts, have been hav=
ing the same misunderstandings and making the same errors for literally dec=
ades. =C2=A0(For example, how long did it take to figure out the <font face=
=3D"monospace, monospace">f(new T, new T)</font> issue?) The designers of J=
ava and C# saw this as a problem to be fixed and chose left-to-right order.=
=C2=A0 There is no good reason for not doing the same in C++, but as I have=
 seen (also for decades), there are plenty of bad ones.</div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Sun, Dec 6, 2015 at 9:52 PM,=
 FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com"=
 target=3D"_blank">frankhb1989@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=886=E6=97=A5=
=E6=98=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=B8=8B=E5=8D=8811:47:04=EF=BC=8CNicol B=
olas=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;paddi=
ng-left:1ex">On Sunday, December 6, 2015 at 3:43:14 AM UTC-5, 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">Sorry for occ=
asional deletion of the original post ...<br><br>=E5=9C=A8 2015=E5=B9=B412=
=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=8812:56=
:15=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<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">P0145R0 is bad for two reasons.=C2=A0 First=
, it (deliberately) does not specify a fixed order of evaluation for all ex=
pressions (thereby failing to solve the problem it ostensibly addresses), a=
nd second, it does not specify that the order should always be strictly lef=
t-to-right (thereby failing to provide a rule which is simple to understand=
). =C2=A0(Point 2 above is thus a consequence.)<br><br></div></blockquote><=
div>This is not totally consequence of the design of the rules or=20
approach of the wording. The root reason is &quot;left-to-right&quot; is=20
essentially and naturally more complicated than &quot;unsequenced&quot; (yo=
u&#39;d=20
define what is &quot;left&quot; and what is &quot;right&quot;). And you can=
&#39;t remove=20
&quot;unsequenced&quot; rules away at all, because there are other use of t=
hem. So
 the result is, you need more words to clarify it, always more wordy.<br></=
div></div></blockquote><div><br>The number of words something takes to stan=
dardize something is not a useful measure of its complexity. Not to the use=
r. After all, most users don&#39;t read the standard.<br><br></div></blockq=
uote></span><div>For this case, it is more or less related.<br><br>Since &q=
uot;left-to-right&quot; rules are not easy to be describe neatly and precis=
ely (in spite of its difficulty of learning), a serious book teaching the=
=C2=A0 language might have to reference the rules quite literally. So words=
 count.<br>=C2=A0<br></div><span class=3D""><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div>What makes something complex to the user is that it does not =
fit the user&#39;s <i>expectations</i>. People who are used to English and =
most European languages read left-to-right, top-to-bottom. As such, their e=
xpectations will be that compilers do things left-to-right, top-to-bottom.<=
br><br></div></blockquote></span><div>For &quot;easy&quot; things, there ar=
e several reasons against this.<br><ul><li>This is false if users&#39; expe=
ctations differ significantly. There are no such single expectations for ev=
eryone. <b>Hiding the fact makes things more difficult.</b> So better keep =
it as-is.</li><li>As a language with built-in side effects support, evaluat=
ion order matters. <b>Fine-grained rules to specify order are needed.</b> E=
xplicit order is one only one special case of it. This is not the case of &=
quot;English and most European languages&quot;. If the users are confused, =
they should learn why they are not the same, not <i>be lazy</i>.</li><li><b=
>Habits are not addicts.</b> If &quot;left-to-right, top-to-bottom&quot; is=
 not always true <i>by need</i> other than &quot;users know that&quot; at f=
irst, it should be abandoned.<br></li><li>Any serious language should not s=
imply copy the pseudo &quot;rules&quot; from the natural languages <i>by de=
sign</i>,
 because it is indeed more complicated than natural languages in nature.
 Yes, I am saying all natural languages are not serious in this sense,=20
because they essentially have <i>no design</i>. The evolution of the &quot;=
rules&quot; (if any) of natural languages is not ruled by the immediate and=
 explicit need of users, <i>by intention</i>.</li><li><b>Evaluation strateg=
y is the very basic knowledge to learn any programming languages.</b> The o=
rder of evaluation is one aspect in it, even this may be not so important i=
f a language provides only pure computation on evaluation. Anyway, this is =
not the case of here. C++ is not so-called &quot;purely functional&quot; la=
nguage at all. You can&#39;t tell users the story about parameters passing =
in English and most European languages, either. Users would meet the whole =
problems (explicit rules different to any natural language) sooner or later=
.. For a language would often used seriously, <b>sooner is better</b>.<br></=
li></ul></div><div><br>And for the order of reading... Why the name lookup =
in class scope <i>sometimes</i> not &quot;top-to-bottom&quot;?<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>A lang=
uage becomes complex when it does not fit users&#39; expectations. When tha=
t happens, you have to look up esoteric rules about how the language actual=
ly behaves. And then you have to later remember those rules when you write =
code.<br><br></div></blockquote></span><div>No, I don&#39;t. I am not a lan=
guage lawyer (e.g. as Richard Smith :). I generally do not to keep rules in=
 mind. I keep the index. When in doubt, I know how to figure out what it sh=
ould be. (And in fact I think most wording are too verbose and not worth re=
membering.) The only exception is 12.8 &quot;when certain criteria are met.=
...&quot; because too many people have asked me why compilers swallow the ca=
lls of copy constructors. Ironically, this rule is far more subtle than any=
 single rule of evaluation order, almost only fit for C++, and almost have =
bitten me <b>at first</b> glance (<b>the evaluation rules did not</b>). But=
 it is still necessary for the design goal and usefulness of C++, so they s=
hould not be removed. So why deliberately remove another useful rule?<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"><d=
iv>For example, let&#39;s say that you switched the meaning of the `for` an=
d `if` keywords. Not today, but way back in the days of C when those keywor=
ds were first designed. It would not make the standard one iota more comple=
x. But it would make <i>understanding</i> the language more complex, becaus=
e you would have conditional statements that use `for` and looping construc=
ts that use `if`. The keywords clearly are wrong here, which requires that =
the user cannot intuit their way through the language. They must learn it b=
y route. That&#39;s more complex.<br><br></div></blockquote><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div>That kind of understanding is the complexity =
we&#39;re trying to reduce here. If we make the language behave the way peo=
ple expect it to, then the language becomes simpler to use.<br><br></div></=
blockquote></span><div>=C2=A0The historical reasons date back to the early =
age of programming=20
languages, earlier than C, i.e. since FORTRAN and ALGOL. Yes, there are=20
some problems. But they are significantly different than the rules you want=
 to remove here. Even the understanding problems are more or less similar f=
or newbies, they should not for skilled users. The redundancy between &quot=
;if&quot; and &quot;for&quot; (or even the ability of recursive calls which=
 original FORTRAN lacks of), is <i>accidental</i>. And it is just <i>redund=
ant</i>. Both points are not applicable for the unsequenced evaluation rule=
s. The &quot;unsequenced&quot; is more natural than &quot;left-to-right&quo=
t; or any hard-coded additional rules if you simply not specified it, at le=
ast for evaluations between arguments of a function.<b></b><br><br>The lega=
cy can have been thrown away, if you want. For=20
example, Scheme does not have built-in loop. It forces the=20
implementation to provide tail call optimization. Any former &quot;keywords=
&quot; dedicated
 for loop constructs can be thus implement trivially as libraries.<br>=C2=
=A0<br></div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><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></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">Point 1 above is wr=
ong.=C2=A0 A change that specifies behavior formerly unspecified cannot be =
breaking.=C2=A0 Implementations that have made promises beyond what the sta=
ndard offers can be broken, but that is not the problem of the committee.=
=C2=A0 Programmers who relied on their implementation&#39;s order are, as p=
er Point 4 above, to be scorned.<br><div><br></div></div></blockquote><div>=
This <i>is </i>a breaking change <b>to implementations</b>. Even if=20
the implementation did not promise anything beyond the standard to the=20
user, the conforming status could be broken in the sense of new stricter
 rules silently, because not all currently conforming implementations=20
obey the new rules. Thus, <b>it is forcing potentially more work on current=
 implementations</b>. It would make problems not existed before.</div></div=
></blockquote><div><br>... so how is that any different from <i>every other=
 change to the standard</i>? Every change is a &quot;breaking change to imp=
lementations&quot;. Every change causes &quot;potentially more work on curr=
ent implementations&quot;.<br><br></div></blockquote></span><div>Other chan=
ges generally benefit. These changes are worthy. Not this one.<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>That&#=
39;s just how it is. That implementations may need to change with the stand=
ard is a statement that is so obvious that pointing it out means nothing.<b=
r><br></div></blockquote></span><div>Obviously.<br>=C2=A0<br></div><span cl=
ass=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The term &quot;breaki=
ng change&quot; doesn&#39;t mean whatever you want it to mean. It has a ver=
y clear and specific meaning in the context of standards: a change to a sta=
ndard where something that had functional behavior before the change no lon=
ger is functional (hence the word &quot;breaking&quot;).<br></div></blockqu=
ote></span><div>Please tell me where does the standard specify the meaning =
of &quot;breaking change&quot;. I know there is annex C, which is informati=
ve and have nothing to do with &quot;breaking&quot; formally, even it would=
 be the focus.<b></b><br><br></div><span class=3D""><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div><br>There is no code which had well-defined behavior =
before that will no longer have well-defined behavior after this change. Th=
erefore, this is not a breaking change.<br></div></blockquote></span><div><=
br>I admit this is not a breaking change on conformance of C++ code. But it
 force the implementation to change. The &quot;breaking&quot; here is just=
=20
stricter than you talked about. In this sense there are still changes=20
not breaking, e.g. fix of editorial issues.<br><br>And now I should=20
emphasize that, this is also breaking for user code since the meaning of
 the program would be altered, even not so many people know what is=20
going on. Please analyze the code formally. <b>I am saying the C++ code is =
being breaking when the rules are changed, not the programs (behavior at en=
d-users&#39; view).</b> <br></div><span class=3D""><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><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"><d=
iv dir=3D"ltr"><div> </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>Point 4 above places the cart squarely in front of=
 the horse.=C2=A0 The reason programmers have so much trouble with the exis=
ting rules is that the existing rules are stupid. </div></div></blockquote>=
<div><br>I don&#39;t find it reasonable. These programmers would have more =
trouble.because new rules are more specific and complicated. And I am sure =
who have no trouble before could have trouble since they need more effort t=
o keep there original intent on the code.<br></div></div></blockquote><div>=
<br>Other languages provide strict guarantees about the order of evaluation=
 of expressions. Yet new programmers don&#39;t find these rules to be &quot=
;more specific and complicated&quot;.<br>=C2=A0</div></blockquote></span><d=
iv>Not all. Scheme has still mandate the order of evaluations in subexpress=
ions of function application &quot;unspecified&quot;.<br><br>Hard-coded add=
itional rules do not make it easy to use once the users=20
are not ignorant to this. They are redundant to skilled users. <b>Why you i=
nsist to keep newbie-friendly but not for others?</b><br>=C2=A0</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"><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></div><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>The way to fix the situation is to fix the s=
tupid rules, not to treat them as a <i>pons asinorum</i>=C2=A0so that smug =
superiority can be asserted.=C2=A0 The code would not be bad if the languag=
e had correct rules.<br><br></div></div></blockquote><div>There is no need =
and no way to &quot;fix&quot; at all. Whatever you proposed to change, the =
change itself makes it more difficult to learn, because old rules are still=
 technically correct and would be with contemporary implementation for a lo=
ng time.</div></div></blockquote><div><br>But then... they won&#39;t be.<br=
></div></blockquote></span><div><br>They would. Even now there a a lot of c=
ompanies use very old implementation as I have known, e.g. Baidu use GCC 3.=
x in their production environment. (And in my experience, G++ does not forc=
e the proposed rules.) Not many people can safely believe the rules are eff=
ective at work. This will not change before it (in C++2x?) widely implement=
ed and used.<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;padd=
ing-left:1ex"><div><br>I&#39;m not sure I understand your point here. You s=
eem to be saying that, because it&#39;ll make things complicated during a t=
ransitional period, we shouldn&#39;t transition at all.<br>=C2=A0</div></bl=
ockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Nonsense. We should d=
esign for the future, not for the past. And in the future, when most compil=
ers have been upgraded to the new standard, we simply won&#39;t have to car=
e about the old rules anymore.<br><br></div></blockquote></span><div>You sh=
ould change if it is a fix of former defects or there are new=20
features worthy. But please don&#39;t introduce changes bad in general (e.g=
.. dynamic exception specification), or changes=20
can&#39;t work in reality for a long time (e.g. &#39;export&#39;, though it=
 is also somewhat &quot;bad&quot;). The change here seem to be fit in both =
sets: bad, and not working in near future.<br>=C2=A0</div><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>The way to fix the problem is =
to <i>fix it</i>. Even if it&#39;s painful for a while, so long as the pain=
 is limited and the destination is far less painful, it is worth doing.<br>=
<br></div></blockquote></span><div>This is not a (right) problem at very fi=
rst. The &quot;fix&quot; is also wrong for its intention. The pain is in va=
in. So it is not worth doing.<br>=C2=A0<br></div><span class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div> How can newbies ignore the old rules?</div></=
div></blockquote><div><br>Very easily; nobody tells them about it.<br>=C2=
=A0</div></blockquote></span><div>They would be in pain again when they bit=
 by UB with old implementations. Please evaluate the probability seriously.=
<br>=C2=A0<br></div><span class=3D""><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><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>How do they=
 figure out whether there are bugs in the old code with the change of the r=
ules?</div></div></blockquote><div><br>How would a &quot;newbie&quot; to C+=
+ see such bugs <i>today</i>, with the current rules? They wouldn&#39;t, be=
cause most newbies basically assume that the compiler evaluates expressions=
 the way they&#39;re written. And we <i>know</i> they assume this because n=
ewbies are <i>far more likely</i> to write code that depends on such evalua=
tions than experienced C++ programmers.<br><br></div></blockquote></span><d=
iv>You must be kidding. Do newbies have rights to deny the actual behavior =
of programs they wrote?<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>So the usual way this plays out is that the &=
quot;newbie&quot; writes bad code, then either an experienced C++ programme=
r sees it or a static analysis tool detects it.<br><br></div></blockquote><=
/span><div>This is even more fancy. Currently, features like [-Wsequenced] =
is encouraged by the existence of current rules. How will programmers adopt=
 such features if the standard do not force them? Trust me, not so many &qu=
ot;experienced&quot; programmers bother to do so.<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>See, newbies don&#3=
9;t fix these bugs; they <i>introduce</i> them. They&#39;re going to write =
that code one way or another. By specifying the evaluation order, we make i=
t so that their code isn&#39;t a bug.<br><br></div></blockquote></span><div=
>That sounds like we are encouraging <i>craps </i>to be produced.<br><br>If=
 a program is with crappy bugs, I don&#39;t think there there is much worth=
 keeping it anymore, because these bugs are so naive and I can&#39;t simply=
 trust it is otherwise somewhat bug-free. It should either be throughout ch=
ecked and fixed, or be rewritten by programmers who would not produce such =
bugs.<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-lef=
t:1ex"><div>That&#39;s a win in my book.<br>=C2=A0</div></blockquote></span=
><div>Which one? <br></div><div class=3D"HOEnZb"><div class=3D"h5"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>Or how do they avoid old code totally? For a language li=
ke C++, no way, practically. They would eventually require to learn the old=
 rules, plus the new one. That is, you&#39;d actually build another <i>pons=
 asinorum</i>, and harm every sane users. The change itself is more stupid =
than any choice of the rules.<br></div></div></blockquote></blockquote><br>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114381e21cfb43052652d1c6--

.

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

"You can go and look" (I didn't complete this) at the Java and C# language
manuals to see how they specify it.  It's not hard or confusing.

On Mon, Dec 7, 2015 at 1:13 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> Left-to-right order is simple to describe. For binary operators, the left
> side is fully evaluated (i.e., all side effects are complete), the right
> side is fully evaluated, then the operation is fully evaluated.  For
> function calls, the function expression is fully evaluated, then each
> parameter is fully initialized in left-to-right order by its correspondin=
g
> fully-evaluated argument expression, with each initialization complete
> before the next one begins (so that an exception in argument evaluation
> neatly destructs the previously initialized parameters).  And so forth.
> You can go and look
>
> The fundamental problem with unspecified order of evaluation is that
> people write code that works as they expect because their implementation
> has the same mental model that they do.  Then one day the implementation
> changes, and all of a sudden the code doesn't work any more.  People,
> including experts, have been having the same misunderstandings and making
> the same errors for literally decades.  (For example, how long did it tak=
e
> to figure out the f(new T, new T) issue?) The designers of Java and C#
> saw this as a problem to be fixed and chose left-to-right order.  There i=
s
> no good reason for not doing the same in C++, but as I have seen (also fo=
r
> decades), there are plenty of bad ones.
>
> On Sun, Dec 6, 2015 at 9:52 PM, FrankHB1989 <frankhb1989@gmail.com> wrote=
:
>
>>
>>
>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 =
UTC+8=E4=B8=8B=E5=8D=8811:47:04=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> On Sunday, December 6, 2015 at 3:43:14 AM UTC-5, FrankHB1989 wrote:
>>>>
>>>> Sorry for occasional deletion of the original post ...
>>>>
>>>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=
=AD UTC+8=E4=B8=8A=E5=8D=8812:56:15=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=
=EF=BC=9A
>>>>>
>>>>> P0145R0 is bad for two reasons.  First, it (deliberately) does not
>>>>> specify a fixed order of evaluation for all expressions (thereby fail=
ing to
>>>>> solve the problem it ostensibly addresses), and second, it does not s=
pecify
>>>>> that the order should always be strictly left-to-right (thereby faili=
ng to
>>>>> provide a rule which is simple to understand).  (Point 2 above is thu=
s a
>>>>> consequence.)
>>>>>
>>>>> This is not totally consequence of the design of the rules or approac=
h
>>>> of the wording. The root reason is "left-to-right" is essentially and
>>>> naturally more complicated than "unsequenced" (you'd define what is "l=
eft"
>>>> and what is "right"). And you can't remove "unsequenced" rules away at=
 all,
>>>> because there are other use of them. So the result is, you need more w=
ords
>>>> to clarify it, always more wordy.
>>>>
>>>
>>> The number of words something takes to standardize something is not a
>>> useful measure of its complexity. Not to the user. After all, most user=
s
>>> don't read the standard.
>>>
>>> For this case, it is more or less related.
>>
>> Since "left-to-right" rules are not easy to be describe neatly and
>> precisely (in spite of its difficulty of learning), a serious book teach=
ing
>> the  language might have to reference the rules quite literally. So word=
s
>> count.
>>
>>
>>> What makes something complex to the user is that it does not fit the
>>> user's *expectations*. People who are used to English and most European
>>> languages read left-to-right, top-to-bottom. As such, their expectation=
s
>>> will be that compilers do things left-to-right, top-to-bottom.
>>>
>>> For "easy" things, there are several reasons against this.
>>
>>    - This is false if users' expectations differ significantly. There
>>    are no such single expectations for everyone. *Hiding the fact makes
>>    things more difficult.* So better keep it as-is.
>>    - As a language with built-in side effects support, evaluation order
>>    matters. *Fine-grained rules to specify order are needed.* Explicit
>>    order is one only one special case of it. This is not the case of "En=
glish
>>    and most European languages". If the users are confused, they should =
learn
>>    why they are not the same, not *be lazy*.
>>    - *Habits are not addicts.* If "left-to-right, top-to-bottom" is not
>>    always true *by need* other than "users know that" at first, it
>>    should be abandoned.
>>    - Any serious language should not simply copy the pseudo "rules" from
>>    the natural languages *by design*, because it is indeed more
>>    complicated than natural languages in nature. Yes, I am saying all na=
tural
>>    languages are not serious in this sense, because they essentially hav=
e *no
>>    design*. The evolution of the "rules" (if any) of natural languages
>>    is not ruled by the immediate and explicit need of users, *by
>>    intention*.
>>    - *Evaluation strategy is the very basic knowledge to learn any
>>    programming languages.* The order of evaluation is one aspect in it,
>>    even this may be not so important if a language provides only pure
>>    computation on evaluation. Anyway, this is not the case of here. C++ =
is not
>>    so-called "purely functional" language at all. You can't tell users t=
he
>>    story about parameters passing in English and most European languages=
,
>>    either. Users would meet the whole problems (explicit rules different=
 to
>>    any natural language) sooner or later. For a language would often use=
d
>>    seriously, *sooner is better*.
>>
>>
>> And for the order of reading... Why the name lookup in class scope
>> *sometimes* not "top-to-bottom"?
>>
>>
>>> A language becomes complex when it does not fit users' expectations.
>>> When that happens, you have to look up esoteric rules about how the
>>> language actually behaves. And then you have to later remember those ru=
les
>>> when you write code.
>>>
>>> No, I don't. I am not a language lawyer (e.g. as Richard Smith :). I
>> generally do not to keep rules in mind. I keep the index. When in doubt,=
 I
>> know how to figure out what it should be. (And in fact I think most word=
ing
>> are too verbose and not worth remembering.) The only exception is 12.8
>> "when certain criteria are met..." because too many people have asked me
>> why compilers swallow the calls of copy constructors. Ironically, this r=
ule
>> is far more subtle than any single rule of evaluation order, almost only
>> fit for C++, and almost have bitten me *at first* glance (*the
>> evaluation rules did not*). But it is still necessary for the design
>> goal and usefulness of C++, so they should not be removed. So why
>> deliberately remove another useful rule?
>>
>>
>>> For example, let's say that you switched the meaning of the `for` and
>>> `if` keywords. Not today, but way back in the days of C when those keyw=
ords
>>> were first designed. It would not make the standard one iota more compl=
ex.
>>> But it would make *understanding* the language more complex, because
>>> you would have conditional statements that use `for` and looping constr=
ucts
>>> that use `if`. The keywords clearly are wrong here, which requires that=
 the
>>> user cannot intuit their way through the language. They must learn it b=
y
>>> route. That's more complex.
>>>
>>> That kind of understanding is the complexity we're trying to reduce
>>> here. If we make the language behave the way people expect it to, then =
the
>>> language becomes simpler to use.
>>>
>>>  The historical reasons date back to the early age of programming
>> languages, earlier than C, i.e. since FORTRAN and ALGOL. Yes, there are
>> some problems. But they are significantly different than the rules you w=
ant
>> to remove here. Even the understanding problems are more or less similar
>> for newbies, they should not for skilled users. The redundancy between "=
if"
>> and "for" (or even the ability of recursive calls which original FORTRAN
>> lacks of), is *accidental*. And it is just *redundant*. Both points are
>> not applicable for the unsequenced evaluation rules. The "unsequenced" i=
s
>> more natural than "left-to-right" or any hard-coded additional rules if =
you
>> simply not specified it, at least for evaluations between arguments of a
>> function.
>>
>> The legacy can have been thrown away, if you want. For example, Scheme
>> does not have built-in loop. It forces the implementation to provide tai=
l
>> call optimization. Any former "keywords" dedicated for loop constructs c=
an
>> be thus implement trivially as libraries.
>>
>>
>>> Point 1 above is wrong.  A change that specifies behavior formerly
>>>>> unspecified cannot be breaking.  Implementations that have made promi=
ses
>>>>> beyond what the standard offers can be broken, but that is not the pr=
oblem
>>>>> of the committee.  Programmers who relied on their implementation's o=
rder
>>>>> are, as per Point 4 above, to be scorned.
>>>>>
>>>>> This *is *a breaking change *to implementations*. Even if the
>>>> implementation did not promise anything beyond the standard to the use=
r,
>>>> the conforming status could be broken in the sense of new stricter rul=
es
>>>> silently, because not all currently conforming implementations obey th=
e new
>>>> rules. Thus, *it is forcing potentially more work on current
>>>> implementations*. It would make problems not existed before.
>>>>
>>>
>>> ... so how is that any different from *every other change to the
>>> standard*? Every change is a "breaking change to implementations".
>>> Every change causes "potentially more work on current implementations".
>>>
>>> Other changes generally benefit. These changes are worthy. Not this one=
..
>>
>>
>>> That's just how it is. That implementations may need to change with the
>>> standard is a statement that is so obvious that pointing it out means
>>> nothing.
>>>
>>> Obviously.
>>
>>
>>> The term "breaking change" doesn't mean whatever you want it to mean. I=
t
>>> has a very clear and specific meaning in the context of standards: a ch=
ange
>>> to a standard where something that had functional behavior before the
>>> change no longer is functional (hence the word "breaking").
>>>
>> Please tell me where does the standard specify the meaning of "breaking
>> change". I know there is annex C, which is informative and have nothing =
to
>> do with "breaking" formally, even it would be the focus.
>>
>>
>>> There is no code which had well-defined behavior before that will no
>>> longer have well-defined behavior after this change. Therefore, this is=
 not
>>> a breaking change.
>>>
>>
>> I admit this is not a breaking change on conformance of C++ code. But it
>> force the implementation to change. The "breaking" here is just stricter
>> than you talked about. In this sense there are still changes not breakin=
g,
>> e.g. fix of editorial issues.
>>
>> And now I should emphasize that, this is also breaking for user code
>> since the meaning of the program would be altered, even not so many peop=
le
>> know what is going on. Please analyze the code formally. *I am saying
>> the C++ code is being breaking when the rules are changed, not the progr=
ams
>> (behavior at end-users' view).*
>>
>>>
>>>
>>>> Point 4 above places the cart squarely in front of the horse.  The
>>>>> reason programmers have so much trouble with the existing rules is th=
at the
>>>>> existing rules are stupid.
>>>>>
>>>>
>>>> I don't find it reasonable. These programmers would have more
>>>> trouble.because new rules are more specific and complicated. And I am =
sure
>>>> who have no trouble before could have trouble since they need more eff=
ort
>>>> to keep there original intent on the code.
>>>>
>>>
>>> Other languages provide strict guarantees about the order of evaluation
>>> of expressions. Yet new programmers don't find these rules to be "more
>>> specific and complicated".
>>>
>>>
>> Not all. Scheme has still mandate the order of evaluations in
>> subexpressions of function application "unspecified".
>>
>> Hard-coded additional rules do not make it easy to use once the users ar=
e
>> not ignorant to this. They are redundant to skilled users. *Why you
>> insist to keep newbie-friendly but not for others?*
>>
>>
>>> The way to fix the situation is to fix the stupid rules, not to treat
>>>>> them as a *pons asinorum* so that smug superiority can be asserted.
>>>>> The code would not be bad if the language had correct rules.
>>>>>
>>>>> There is no need and no way to "fix" at all. Whatever you proposed to
>>>> change, the change itself makes it more difficult to learn, because ol=
d
>>>> rules are still technically correct and would be with contemporary
>>>> implementation for a long time.
>>>>
>>>
>>> But then... they won't be.
>>>
>>
>> They would. Even now there a a lot of companies use very old
>> implementation as I have known, e.g. Baidu use GCC 3.x in their producti=
on
>> environment. (And in my experience, G++ does not force the proposed rule=
s.)
>> Not many people can safely believe the rules are effective at work. This
>> will not change before it (in C++2x?) widely implemented and used.
>>
>>
>>>
>>> I'm not sure I understand your point here. You seem to be saying that,
>>> because it'll make things complicated during a transitional period, we
>>> shouldn't transition at all.
>>>
>>>
>> Nonsense. We should design for the future, not for the past. And in the
>>> future, when most compilers have been upgraded to the new standard, we
>>> simply won't have to care about the old rules anymore.
>>>
>>> You should change if it is a fix of former defects or there are new
>> features worthy. But please don't introduce changes bad in general (e.g.
>> dynamic exception specification), or changes can't work in reality for a
>> long time (e.g. 'export', though it is also somewhat "bad"). The change
>> here seem to be fit in both sets: bad, and not working in near future.
>>
>>
>>> The way to fix the problem is to *fix it*. Even if it's painful for a
>>> while, so long as the pain is limited and the destination is far less
>>> painful, it is worth doing.
>>>
>>> This is not a (right) problem at very first. The "fix" is also wrong fo=
r
>> its intention. The pain is in vain. So it is not worth doing.
>>
>>
>>> How can newbies ignore the old rules?
>>>>
>>>
>>> Very easily; nobody tells them about it.
>>>
>>>
>> They would be in pain again when they bit by UB with old implementations=
..
>> Please evaluate the probability seriously.
>>
>>
>>> How do they figure out whether there are bugs in the old code with the
>>>> change of the rules?
>>>>
>>>
>>> How would a "newbie" to C++ see such bugs *today*, with the current
>>> rules? They wouldn't, because most newbies basically assume that the
>>> compiler evaluates expressions the way they're written. And we *know*
>>> they assume this because newbies are *far more likely* to write code
>>> that depends on such evaluations than experienced C++ programmers.
>>>
>>> You must be kidding. Do newbies have rights to deny the actual behavior
>> of programs they wrote?
>>
>>
>>> So the usual way this plays out is that the "newbie" writes bad code,
>>> then either an experienced C++ programmer sees it or a static analysis =
tool
>>> detects it.
>>>
>>> This is even more fancy. Currently, features like [-Wsequenced] is
>> encouraged by the existence of current rules. How will programmers adopt
>> such features if the standard do not force them? Trust me, not so many
>> "experienced" programmers bother to do so.
>>
>>
>>> See, newbies don't fix these bugs; they *introduce* them. They're going
>>> to write that code one way or another. By specifying the evaluation ord=
er,
>>> we make it so that their code isn't a bug.
>>>
>>> That sounds like we are encouraging *craps *to be produced.
>>
>> If a program is with crappy bugs, I don't think there there is much wort=
h
>> keeping it anymore, because these bugs are so naive and I can't simply
>> trust it is otherwise somewhat bug-free. It should either be throughout
>> checked and fixed, or be rewritten by programmers who would not produce
>> such bugs.
>>
>>
>>> That's a win in my book.
>>>
>>>
>> Which one?
>>
>>> Or how do they avoid old code totally? For a language like C++, no way,
>>>> practically. They would eventually require to learn the old rules, plu=
s the
>>>> new one. That is, you'd actually build another *pons asinorum*, and
>>>> harm every sane users. The change itself is more stupid than any choic=
e of
>>>> the rules.
>>>>
>>>
>> --
>>
>> ---
>> 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.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">&quot;You can go and look&quot; (I didn&#39;t complete thi=
s) at the Java and C# language manuals to see how they specify it.=C2=A0 It=
&#39;s not hard or confusing.</div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Mon, Dec 7, 2015 at 1:13 PM, Hyman Rosen <span dir=3D"=
ltr">&lt;<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.r=
osen@gmail.com</a>&gt;</span> wrote:<br><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">Left-to-right order is simple to describe. For binary operator=
s, the left side is fully evaluated (i.e., all side effects are complete), =
the right side is fully evaluated, then the operation is fully evaluated.=
=C2=A0 For function calls, the function expression is fully evaluated, then=
 each parameter is fully initialized in left-to-right order by its correspo=
nding fully-evaluated argument expression, with each initialization complet=
e before the next one begins (so that an exception in argument evaluation n=
eatly destructs the previously initialized parameters).=C2=A0 And so forth.=
=C2=A0 You can go and look=C2=A0<br><br>The fundamental problem with unspec=
ified order of evaluation is that people write code that works as they expe=
ct because their implementation has the same mental model that they do.=C2=
=A0 Then one day the implementation changes, and all of a sudden the code d=
oesn&#39;t work any more.=C2=A0 People, including experts, have been having=
 the same misunderstandings and making the same errors for literally decade=
s. =C2=A0(For example, how long did it take to figure out the <font face=3D=
"monospace, monospace">f(new T, new T)</font> issue?) The designers of Java=
 and C# saw this as a problem to be fixed and chose left-to-right order.=C2=
=A0 There is no good reason for not doing the same in C++, but as I have se=
en (also for decades), there are plenty of bad ones.</div><div class=3D"HOE=
nZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Sun, Dec 6, 2015 at 9:52 PM, FrankHB1989 <span dir=3D"ltr">&lt;<a =
href=3D"mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>=E5=9C=
=A8 2015=E5=B9=B412=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=
=B8=8B=E5=8D=8811:47:04=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<span=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">On Sunday, December 6, 2015 at 3:4=
3:14 AM UTC-5, FrankHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">Sorry for occasional deletion of the original post ...<br><b=
r>=E5=9C=A8 2015=E5=B9=B412=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8A=E5=8D=8812:56:15=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;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">P0145R0 is bad =
for two reasons.=C2=A0 First, it (deliberately) does not specify a fixed or=
der of evaluation for all expressions (thereby failing to solve the problem=
 it ostensibly addresses), and second, it does not specify that the order s=
hould always be strictly left-to-right (thereby failing to provide a rule w=
hich is simple to understand). =C2=A0(Point 2 above is thus a consequence.)=
<br><br></div></blockquote><div>This is not totally consequence of the desi=
gn of the rules or=20
approach of the wording. The root reason is &quot;left-to-right&quot; is=20
essentially and naturally more complicated than &quot;unsequenced&quot; (yo=
u&#39;d=20
define what is &quot;left&quot; and what is &quot;right&quot;). And you can=
&#39;t remove=20
&quot;unsequenced&quot; rules away at all, because there are other use of t=
hem. So
 the result is, you need more words to clarify it, always more wordy.<br></=
div></div></blockquote><div><br>The number of words something takes to stan=
dardize something is not a useful measure of its complexity. Not to the use=
r. After all, most users don&#39;t read the standard.<br><br></div></blockq=
uote></span><div>For this case, it is more or less related.<br><br>Since &q=
uot;left-to-right&quot; rules are not easy to be describe neatly and precis=
ely (in spite of its difficulty of learning), a serious book teaching the=
=C2=A0 language might have to reference the rules quite literally. So words=
 count.<br>=C2=A0<br></div><span><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv>What makes something complex to the user is that it does not fit the use=
r&#39;s <i>expectations</i>. People who are used to English and most Europe=
an languages read left-to-right, top-to-bottom. As such, their expectations=
 will be that compilers do things left-to-right, top-to-bottom.<br><br></di=
v></blockquote></span><div>For &quot;easy&quot; things, there are several r=
easons against this.<br><ul><li>This is false if users&#39; expectations di=
ffer significantly. There are no such single expectations for everyone. <b>=
Hiding the fact makes things more difficult.</b> So better keep it as-is.</=
li><li>As a language with built-in side effects support, evaluation order m=
atters. <b>Fine-grained rules to specify order are needed.</b> Explicit ord=
er is one only one special case of it. This is not the case of &quot;Englis=
h and most European languages&quot;. If the users are confused, they should=
 learn why they are not the same, not <i>be lazy</i>.</li><li><b>Habits are=
 not addicts.</b> If &quot;left-to-right, top-to-bottom&quot; is not always=
 true <i>by need</i> other than &quot;users know that&quot; at first, it sh=
ould be abandoned.<br></li><li>Any serious language should not simply copy =
the pseudo &quot;rules&quot; from the natural languages <i>by design</i>,
 because it is indeed more complicated than natural languages in nature.
 Yes, I am saying all natural languages are not serious in this sense,=20
because they essentially have <i>no design</i>. The evolution of the &quot;=
rules&quot; (if any) of natural languages is not ruled by the immediate and=
 explicit need of users, <i>by intention</i>.</li><li><b>Evaluation strateg=
y is the very basic knowledge to learn any programming languages.</b> The o=
rder of evaluation is one aspect in it, even this may be not so important i=
f a language provides only pure computation on evaluation. Anyway, this is =
not the case of here. C++ is not so-called &quot;purely functional&quot; la=
nguage at all. You can&#39;t tell users the story about parameters passing =
in English and most European languages, either. Users would meet the whole =
problems (explicit rules different to any natural language) sooner or later=
.. For a language would often used seriously, <b>sooner is better</b>.<br></=
li></ul></div><div><br>And for the order of reading... Why the name lookup =
in class scope <i>sometimes</i> not &quot;top-to-bottom&quot;?<br>=C2=A0<br=
></div><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>A language become=
s complex when it does not fit users&#39; expectations. When that happens, =
you have to look up esoteric rules about how the language actually behaves.=
 And then you have to later remember those rules when you write code.<br><b=
r></div></blockquote></span><div>No, I don&#39;t. I am not a language lawye=
r (e.g. as Richard Smith :). I generally do not to keep rules in mind. I ke=
ep the index. When in doubt, I know how to figure out what it should be. (A=
nd in fact I think most wording are too verbose and not worth remembering.)=
 The only exception is 12.8 &quot;when certain criteria are met...&quot; be=
cause too many people have asked me why compilers swallow the calls of copy=
 constructors. Ironically, this rule is far more subtle than any single rul=
e of evaluation order, almost only fit for C++, and almost have bitten me <=
b>at first</b> glance (<b>the evaluation rules did not</b>). But it is stil=
l necessary for the design goal and usefulness of C++, so they should not b=
e removed. So why deliberately remove another useful rule?<br>=C2=A0<br></d=
iv><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>For example, let&#39;=
s say that you switched the meaning of the `for` and `if` keywords. Not tod=
ay, but way back in the days of C when those keywords were first designed. =
It would not make the standard one iota more complex. But it would make <i>=
understanding</i> the language more complex, because you would have conditi=
onal statements that use `for` and looping constructs that use `if`. The ke=
ywords clearly are wrong here, which requires that the user cannot intuit t=
heir way through the language. They must learn it by route. That&#39;s more=
 complex.<br><br></div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div>That kind of understanding is the complexity we&#39;re trying to redu=
ce here. If we make the language behave the way people expect it to, then t=
he language becomes simpler to use.<br><br></div></blockquote></span><div>=
=C2=A0The historical reasons date back to the early age of programming=20
languages, earlier than C, i.e. since FORTRAN and ALGOL. Yes, there are=20
some problems. But they are significantly different than the rules you want=
 to remove here. Even the understanding problems are more or less similar f=
or newbies, they should not for skilled users. The redundancy between &quot=
;if&quot; and &quot;for&quot; (or even the ability of recursive calls which=
 original FORTRAN lacks of), is <i>accidental</i>. And it is just <i>redund=
ant</i>. Both points are not applicable for the unsequenced evaluation rule=
s. The &quot;unsequenced&quot; is more natural than &quot;left-to-right&quo=
t; or any hard-coded additional rules if you simply not specified it, at le=
ast for evaluations between arguments of a function.<b></b><br><br>The lega=
cy can have been thrown away, if you want. For=20
example, Scheme does not have built-in loop. It forces the=20
implementation to provide tail call optimization. Any former &quot;keywords=
&quot; dedicated
 for loop constructs can be thus implement trivially as libraries.<br>=C2=
=A0<br></div><span><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><bloc=
kquote 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><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">Point 1 above is wrong.=C2=A0 =
A change that specifies behavior formerly unspecified cannot be breaking.=
=C2=A0 Implementations that have made promises beyond what the standard off=
ers can be broken, but that is not the problem of the committee.=C2=A0 Prog=
rammers who relied on their implementation&#39;s order are, as per Point 4 =
above, to be scorned.<br><div><br></div></div></blockquote><div>This <i>is =
</i>a breaking change <b>to implementations</b>. Even if=20
the implementation did not promise anything beyond the standard to the=20
user, the conforming status could be broken in the sense of new stricter
 rules silently, because not all currently conforming implementations=20
obey the new rules. Thus, <b>it is forcing potentially more work on current=
 implementations</b>. It would make problems not existed before.</div></div=
></blockquote><div><br>... so how is that any different from <i>every other=
 change to the standard</i>? Every change is a &quot;breaking change to imp=
lementations&quot;. Every change causes &quot;potentially more work on curr=
ent implementations&quot;.<br><br></div></blockquote></span><div>Other chan=
ges generally benefit. These changes are worthy. Not this one.<br>=C2=A0<br=
></div><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>That&#39;s just h=
ow it is. That implementations may need to change with the standard is a st=
atement that is so obvious that pointing it out means nothing.<br><br></div=
></blockquote></span><div>Obviously.<br>=C2=A0<br></div><span><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>The term &quot;breaking change&quot; doesn&=
#39;t mean whatever you want it to mean. It has a very clear and specific m=
eaning in the context of standards: a change to a standard where something =
that had functional behavior before the change no longer is functional (hen=
ce the word &quot;breaking&quot;).<br></div></blockquote></span><div>Please=
 tell me where does the standard specify the meaning of &quot;breaking chan=
ge&quot;. I know there is annex C, which is informative and have nothing to=
 do with &quot;breaking&quot; formally, even it would be the focus.<b></b><=
br><br></div><span><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>There i=
s no code which had well-defined behavior before that will no longer have w=
ell-defined behavior after this change. Therefore, this is not a breaking c=
hange.<br></div></blockquote></span><div><br>I admit this is not a breaking=
 change on conformance of C++ code. But it
 force the implementation to change. The &quot;breaking&quot; here is just=
=20
stricter than you talked about. In this sense there are still changes=20
not breaking, e.g. fix of editorial issues.<br><br>And now I should=20
emphasize that, this is also breaking for user code since the meaning of
 the program would be altered, even not so many people know what is=20
going on. Please analyze the code formally. <b>I am saying the C++ code is =
being breaking when the rules are changed, not the programs (behavior at en=
d-users&#39; view).</b> <br></div><span><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div>=C2=A0</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"l=
tr"><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"><d=
iv></div><div>Point 4 above places the cart squarely in front of the horse.=
=C2=A0 The reason programmers have so much trouble with the existing rules =
is that the existing rules are stupid. </div></div></blockquote><div><br>I =
don&#39;t find it reasonable. These programmers would have more trouble.bec=
ause new rules are more specific and complicated. And I am sure who have no=
 trouble before could have trouble since they need more effort to keep ther=
e original intent on the code.<br></div></div></blockquote><div><br>Other l=
anguages provide strict guarantees about the order of evaluation of express=
ions. Yet new programmers don&#39;t find these rules to be &quot;more speci=
fic and complicated&quot;.<br>=C2=A0</div></blockquote></span><div>Not all.=
 Scheme has still mandate the order of evaluations in subexpressions of fun=
ction application &quot;unspecified&quot;.<br><br>Hard-coded additional rul=
es do not make it easy to use once the users=20
are not ignorant to this. They are redundant to skilled users. <b>Why you i=
nsist to keep newbie-friendly but not for others?</b><br>=C2=A0</div><span>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" s=
tyle=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"><d=
iv dir=3D"ltr"><div>The way to fix the situation is to fix the stupid rules=
, not to treat them as a <i>pons asinorum</i>=C2=A0so that smug superiority=
 can be asserted.=C2=A0 The code would not be bad if the language had corre=
ct rules.<br><br></div></div></blockquote><div>There is no need and no way =
to &quot;fix&quot; at all. Whatever you proposed to change, the change itse=
lf makes it more difficult to learn, because old rules are still technicall=
y correct and would be with contemporary implementation for a long time.</d=
iv></div></blockquote><div><br>But then... they won&#39;t be.<br></div></bl=
ockquote></span><div><br>They would. Even now there a a lot of companies us=
e very old implementation as I have known, e.g. Baidu use GCC 3.x in their =
production environment. (And in my experience, G++ does not force the propo=
sed rules.) Not many people can safely believe the rules are effective at w=
ork. This will not change before it (in C++2x?) widely implemented and used=
..<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><br=
>I&#39;m not sure I understand your point here. You seem to be saying that,=
 because it&#39;ll make things complicated during a transitional period, we=
 shouldn&#39;t transition at all.<br>=C2=A0</div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>Nonsense. We should design for the future, =
not for the past. And in the future, when most compilers have been upgraded=
 to the new standard, we simply won&#39;t have to care about the old rules =
anymore.<br><br></div></blockquote></span><div>You should change if it is a=
 fix of former defects or there are new=20
features worthy. But please don&#39;t introduce changes bad in general (e.g=
.. dynamic exception specification), or changes=20
can&#39;t work in reality for a long time (e.g. &#39;export&#39;, though it=
 is also somewhat &quot;bad&quot;). The change here seem to be fit in both =
sets: bad, and not working in near future.<br>=C2=A0</div><span><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div>The way to fix the problem is to <i>fix i=
t</i>. Even if it&#39;s painful for a while, so long as the pain is limited=
 and the destination is far less painful, it is worth doing.<br><br></div><=
/blockquote></span><div>This is not a (right) problem at very first. The &q=
uot;fix&quot; is also wrong for its intention. The pain is in vain. So it i=
s not worth doing.<br>=C2=A0<br></div><span><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div></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> How can newbies ignore the old rules?</div></div></blockquote><div>=
<br>Very easily; nobody tells them about it.<br>=C2=A0</div></blockquote></=
span><div>They would be in pain again when they bit by UB with old implemen=
tations. Please evaluate the probability seriously.<br>=C2=A0<br></div><spa=
n><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>How do they figure out whether there are bugs =
in the old code with the change of the rules?</div></div></blockquote><div>=
<br>How would a &quot;newbie&quot; to C++ see such bugs <i>today</i>, with =
the current rules? They wouldn&#39;t, because most newbies basically assume=
 that the compiler evaluates expressions the way they&#39;re written. And w=
e <i>know</i> they assume this because newbies are <i>far more likely</i> t=
o write code that depends on such evaluations than experienced C++ programm=
ers.<br><br></div></blockquote></span><div>You must be kidding. Do newbies =
have rights to deny the actual behavior of programs they wrote?<br>=C2=A0<b=
r></div><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>So the usual way=
 this plays out is that the &quot;newbie&quot; writes bad code, then either=
 an experienced C++ programmer sees it or a static analysis tool detects it=
..<br><br></div></blockquote></span><div>This is even more fancy. Currently,=
 features like [-Wsequenced] is encouraged by the existence of current rule=
s. How will programmers adopt such features if the standard do not force th=
em? Trust me, not so many &quot;experienced&quot; programmers bother to do =
so.<br>=C2=A0<br></div><span><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>S=
ee, newbies don&#39;t fix these bugs; they <i>introduce</i> them. They&#39;=
re going to write that code one way or another. By specifying the evaluatio=
n order, we make it so that their code isn&#39;t a bug.<br><br></div></bloc=
kquote></span><div>That sounds like we are encouraging <i>craps </i>to be p=
roduced.<br><br>If a program is with crappy bugs, I don&#39;t think there t=
here is much worth keeping it anymore, because these bugs are so naive and =
I can&#39;t simply trust it is otherwise somewhat bug-free. It should eithe=
r be throughout checked and fixed, or be rewritten by programmers who would=
 not produce such bugs.<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>That&#39;s a win in my book.<br>=C2=A0</div></blockquote=
></span><div>Which one? <br></div><div><div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><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>Or h=
ow do they avoid old code totally? For a language like C++, no way, practic=
ally. They would eventually require to learn the old rules, plus the new on=
e. That is, you&#39;d actually build another <i>pons asinorum</i>, and harm=
 every sane users. The change itself is more stupid than any choice of the =
rules.<br></div></div></blockquote></blockquote><br>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a114381e2b57397052652d937--

.

------=_Part_6993_1636487544.1449517679388
Content-Type: multipart/alternative;
 boundary="----=_Part_6994_452021339.1449517679389"

------=_Part_6994_452021339.1449517679389
Content-Type: text/plain; charset=UTF-8

The idea I have is to take a middle approach: establish a couple of
sequence points to avoid confusion.

I think that it's fine to say that function parameters are evaluated in an
arbitrary order, as are subexpressions in most binary operators (e.g.
meow() + kitty() can call the functions in either order).  However, there
are a couple of places where the binary operator needs to have a defined
order, in my opinion:

first, second    (already sequenced)
first ? second : second    (already sequenced)
first.*second
first->*second
first(second...)
first << second    (when overloaded only?)
first >> second    (when overloaded only?)

It's really confusing that (new T)->Function(Meow()); can call Meow before
T::operator new and T::T.


On Sunday, December 6, 2015 at 7:47:04 AM UTC-8, Nicol Bolas wrote:

> A language becomes complex when it does not fit users' expectations. When
> that happens, you have to look up esoteric rules about how the language
> actually behaves. And then you have to later remember those rules when you
> write code.
>

Now if only this applied to signed integer overflow and to unsigned types
promoting to signed types...  Or to reinterpret_casting unrelated types...


Melissa

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">The idea I have is to take a middle approach: establish a =
couple of sequence points to avoid confusion.<br><br>I think that it&#39;s =
fine to say that function parameters are evaluated in an arbitrary order, a=
s are subexpressions in most binary operators (e.g. meow() + kitty() can ca=
ll the functions in either order).=C2=A0 However, there are a couple of pla=
ces where the binary operator needs to have a defined order, in my opinion:=
<br><br>first, second=C2=A0=C2=A0=C2=A0 (already sequenced)<br>first ? seco=
nd : second=C2=A0 =C2=A0 (already sequenced)<br>first.*second<br>first-&gt;=
*second<br>first(second...)<br>first &lt;&lt; second=C2=A0=C2=A0=C2=A0 (whe=
n overloaded only?)<br>first &gt;&gt; second=C2=A0=C2=A0=C2=A0 (when overlo=
aded only?)<br><br>It&#39;s really confusing that (new T)-&gt;Function(Meow=
()); can call Meow before T::operator new and T::T.<br><br><br>On Sunday, D=
ecember 6, 2015 at 7:47:04 AM UTC-8, Nicol Bolas wrote:<br><blockquote styl=
e=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); =
padding-left: 1ex;" class=3D"gmail_quote">A
 language becomes complex when it does not fit users&#39; expectations. Whe=
n
 that happens, you have to look up esoteric rules about how the language
 actually behaves. And then you have to later remember those rules when=20
you write code.<br></blockquote><br>Now if only this applied to signed inte=
ger overflow and to unsigned types promoting to signed types...=C2=A0 Or to=
 reinterpret_casting unrelated types...<br><br><br>Melissa<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6994_452021339.1449517679389--
------=_Part_6993_1636487544.1449517679388--

.

------=_Part_5511_695709101.1449518290147
Content-Type: multipart/alternative;
 boundary="----=_Part_5512_1554028548.1449518290147"

------=_Part_5512_1554028548.1449518290147
Content-Type: text/plain; charset=UTF-8

On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wrote:

> <snip>
>

Then I guess we're going to have to agree to disagree then.

I don't buy that the fact that something takes more words to describe
inherently makes it meaningfully more complex. I don't accept your idea
that changing the language to better fit users expectations is is somehow
hiding something from them.

I don't even understand what "C++ code is being breaking when the rules are
changed, not the programs" is supposed to mean.

I don't accept your assertion that changing code to match user's
expectations is being unfriendly to experienced users. I do not buy into
your belief that code written with the expectation of this behavior is a
priori "crap" even if the standard made it well-defined.

I do not find any of your arguments to be the slightest bit convincing, but
it's clear that explaining why will not move this discussion further.

However, there is one point I would specifically like to respond to:

They would be in pain again when they bit by UB with old implementations.
> Please evaluate the probability seriously.
>

Very well; let's "evaluate the probability seriously".

Jump ahead 2 years. C++17 incorporates these ordering rules. Some people
start writing code against C++17 that deliberately relies on these rules
(as opposed to accidentally relying on them).

Of course, since they're writing C++17 code that is meant for a C++17
compiler, they will almost certainly also be writing code that relies on
*other* C++17 features. Maybe they're using multiple-return-values through
tuples. Maybe concepts was adopted into C++17. Maybe they'll be using the
many new standard library objects adopted into C++17.

None of these features will compile on "old implementations". Therefore,
the only time the situation you describe could be a problem is if someone
has written code that relies on exactly and *only *this one feature of C++17
*.*

What reason do you have to believe that this would be a *likely*
eventuality? Could it bite someone? Sure. Is that "probable"? No.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB19=
89 wrote:<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">&lt;=
snip&gt;<br></blockquote><div><br>Then I guess we&#39;re going to have to a=
gree to disagree then.<br><br>I don&#39;t buy that the fact that something =
takes more words to describe inherently makes it meaningfully more complex.=
 I don&#39;t accept your idea that changing the language to better fit user=
s expectations is is somehow hiding something from them.<br><br>I don&#39;t=
 even understand what &quot;C++ code is being breaking when the rules are c=
hanged, not the programs&quot; is supposed to mean.<br><br>I don&#39;t acce=
pt your assertion that changing code to match user&#39;s expectations is be=
ing unfriendly to experienced users. I do not buy into your belief that cod=
e written with the expectation of this behavior is a priori &quot;crap&quot=
; even if the standard made it well-defined.<br><br>I do not find any of yo=
ur arguments to be the slightest bit convincing, but it&#39;s clear that ex=
plaining why will not move this discussion further.<br><br>However, there i=
s one point I would specifically like to respond to:<br><br><blockquote sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;" class=3D"gmail_quote">They would be in pain again when=
 they bit by UB with old implementations. Please evaluate the probability s=
eriously.<br></blockquote></div><br>Very well; let&#39;s &quot;evaluate the=
 probability seriously&quot;.<br><br>Jump ahead 2 years. C++17 incorporates=
 these ordering rules. Some people start writing code against C++17 that de=
liberately relies on these rules (as opposed to accidentally relying on the=
m).<br><br>Of course, since they&#39;re writing C++17 code that is meant fo=
r a C++17 compiler, they will almost certainly also be writing code that re=
lies on <i>other</i> C++17 features. Maybe they&#39;re using multiple-retur=
n-values through tuples. Maybe concepts was adopted into C++17. Maybe they&=
#39;ll be using the many new standard library objects adopted into C++17.<b=
r><br>None of these features will compile on &quot;old implementations&quot=
;. Therefore, the only time the situation you describe could be a problem i=
s if someone has written code that relies on exactly and <i>only </i>this o=
ne feature of C++17<i>.</i><br><i><br></i>What reason do you have to believ=
e that this would be a <i>likely</i> eventuality? Could it bite someone? Su=
re. Is that &quot;probable&quot;? No.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5512_1554028548.1449518290147--
------=_Part_5511_695709101.1449518290147--

.

------=_Part_736_769553223.1449519338477
Content-Type: multipart/alternative;
 boundary="----=_Part_737_1752199366.1449519338477"

------=_Part_737_1752199366.1449519338477
Content-Type: text/plain; charset=UTF-8

On Monday, December 7, 2015 at 2:47:59 PM UTC-5, Myriachan wrote:
>
> The idea I have is to take a middle approach: establish a couple of
> sequence points to avoid confusion.
>

That's essentially what the paper does. After all, it doesn't define order
for everything; only for specific, cherry-picked cases.

The difference is which cases it considers important.

Personally, I prefer a standardized ordering guarantee for everything, not
cherry picking. That only makes the language more complicated, as it
encourages you to think it works the way you think it does... until it
doesn't.


> On Sunday, December 6, 2015 at 7:47:04 AM UTC-8, Nicol Bolas wrote:
>
>> A language becomes complex when it does not fit users' expectations. When
>> that happens, you have to look up esoteric rules about how the language
>> actually behaves. And then you have to later remember those rules when you
>> write code.
>>
>
> Now if only this applied to signed integer overflow and to unsigned types
> promoting to signed types...  Or to reinterpret_casting unrelated types...
>

Well, the signed/unsigned thing is about casting a wide net in terms of
implementations. Some people really do need to work on non-two's complement
machines.

As for casting... no.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, December 7, 2015 at 2:47:59 PM UTC-5, Myriachan=
 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 id=
ea I have is to take a middle approach: establish a couple of sequence poin=
ts to avoid confusion.<br></div></blockquote><div><br>That&#39;s essentiall=
y what the paper does. After all, it doesn&#39;t define order for everythin=
g; only for specific, cherry-picked cases.<br><br>The difference is which c=
ases it considers important.<br><br>Personally, I prefer a standardized ord=
ering guarantee for everything, not cherry picking. That only makes the lan=
guage more complicated, as it encourages you to think it works the way you =
think it does... until it doesn&#39;t.<br>=C2=A0</div><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">On Sunday, December 6, 2015 at 7:4=
7:04 AM UTC-8, Nicol Bolas wrote:<br><blockquote style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"g=
mail_quote">A
 language becomes complex when it does not fit users&#39; expectations. Whe=
n
 that happens, you have to look up esoteric rules about how the language
 actually behaves. And then you have to later remember those rules when=20
you write code.<br></blockquote><br>Now if only this applied to signed inte=
ger overflow and to unsigned types promoting to signed types...=C2=A0 Or to=
 reinterpret_casting unrelated types...<br></div></blockquote><div><br>Well=
, the signed/unsigned thing is about casting a wide net in terms of impleme=
ntations. Some people really do need to work on non-two&#39;s complement ma=
chines.<br><br>As for casting... no.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_737_1752199366.1449519338477--
------=_Part_736_769553223.1449519338477--

.

------=_Part_6855_1004143333.1449520485866
Content-Type: multipart/alternative;
 boundary="----=_Part_6856_767311062.1449520485866"

------=_Part_6856_767311062.1449520485866
Content-Type: text/plain; charset=UTF-8

On Monday, December 7, 2015 at 12:15:38 PM UTC-8, Nicol Bolas wrote:
>
> On Monday, December 7, 2015 at 2:47:59 PM UTC-5, Myriachan wrote:
>>
>> The idea I have is to take a middle approach: establish a couple of
>> sequence points to avoid confusion.
>>
>
> That's essentially what the paper does. After all, it doesn't define order
> for everything; only for specific, cherry-picked cases.
>
> The difference is which cases it considers important.
>
> Personally, I prefer a standardized ordering guarantee for everything, not
> cherry picking. That only makes the language more complicated, as it
> encourages you to think it works the way you think it does... until it
> doesn't.
>
>
>> On Sunday, December 6, 2015 at 7:47:04 AM UTC-8, Nicol Bolas wrote:
>>
>>> A language becomes complex when it does not fit users' expectations.
>>> When that happens, you have to look up esoteric rules about how the
>>> language actually behaves. And then you have to later remember those rules
>>> when you write code.
>>>
>>
>> Now if only this applied to signed integer overflow and to unsigned types
>> promoting to signed types...  Or to reinterpret_casting unrelated types...
>>
>
> Well, the signed/unsigned thing is about casting a wide net in terms of
> implementations. Some people really do need to work on non-two's complement
> machines.
>
>
Then define it as one of a set of { wrapping, saturating, trapping },
implementation's choice.  Not { wrapping, saturating, trapping, nasal
demons }.


> As for casting... no.
>

Then we should remove union from the language, because the current
definition is inconsistent when combined with other aspects of the language.

Melissa

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, December 7, 2015 at 12:15:38 PM UTC-8, Nicol Bolas wrote:<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">On Monday, December =
7, 2015 at 2:47:59 PM UTC-5, Myriachan 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">The idea I have is to take a middle approach: es=
tablish a couple of sequence points to avoid confusion.<br></div></blockquo=
te><div><br>That&#39;s essentially what the paper does. After all, it doesn=
&#39;t define order for everything; only for specific, cherry-picked cases.=
<br><br>The difference is which cases it considers important.<br><br>Person=
ally, I prefer a standardized ordering guarantee for everything, not cherry=
 picking. That only makes the language more complicated, as it encourages y=
ou to think it works the way you think it does... until it doesn&#39;t.<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">On Sun=
day, December 6, 2015 at 7:47:04 AM UTC-8, Nicol Bolas wrote:<br><blockquot=
e style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex" class=3D"gmail_quote">A
 language becomes complex when it does not fit users&#39; expectations. Whe=
n
 that happens, you have to look up esoteric rules about how the language
 actually behaves. And then you have to later remember those rules when=20
you write code.<br></blockquote><br>Now if only this applied to signed inte=
ger overflow and to unsigned types promoting to signed types...=C2=A0 Or to=
 reinterpret_casting unrelated types...<br></div></blockquote><div><br>Well=
, the signed/unsigned thing is about casting a wide net in terms of impleme=
ntations. Some people really do need to work on non-two&#39;s complement ma=
chines.<br><br></div></div></blockquote><div><br>Then define it as one of a=
 set of { wrapping, saturating, trapping }, implementation&#39;s choice.=C2=
=A0 Not { wrapping, saturating, trapping, nasal demons }.<br>=C2=A0</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>As for cas=
ting... no.<br></div></div></blockquote><div><br>Then we should remove unio=
n from the language, because the current definition is inconsistent when co=
mbined with other aspects of the language.<br><br>Melissa <br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6856_767311062.1449520485866--
------=_Part_6855_1004143333.1449520485866--

.

This is a multi-part message in MIME format.
--------------090203000600000903060309
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 07.12.2015 um 21:34 schrieb Myriachan:
> On Monday, December 7, 2015 at 12:15:38 PM UTC-8, Nicol Bolas wrote:
>
>     On Monday, December 7, 2015 at 2:47:59 PM UTC-5, Myriachan wrote:
>
>         The idea I have is to take a middle approach: establish a
>         couple of sequence points to avoid confusion.
>
>
>     That's essentially what the paper does. After all, it doesn't
>     define order for everything; only for specific, cherry-picked cases.
>
>     The difference is which cases it considers important.
>
>     Personally, I prefer a standardized ordering guarantee for
>     everything, not cherry picking. That only makes the language more
>     complicated, as it encourages you to think it works the way you
>     think it does... until it doesn't.
>
>         On Sunday, December 6, 2015 at 7:47:04 AM UTC-8, Nicol Bolas
>         wrote:
>
>             A language becomes complex when it does not fit users'
>             expectations. When that happens, you have to look up
>             esoteric rules about how the language actually behaves.
>             And then you have to later remember those rules when you
>             write code.
>
>
>         Now if only this applied to signed integer overflow and to
>         unsigned types promoting to signed types...  Or to
>         reinterpret_casting unrelated types...
>
>
>     Well, the signed/unsigned thing is about casting a wide net in
>     terms of implementations. Some people really do need to work on
>     non-two's complement machines.
>
>
> Then define it as one of a set of { wrapping, saturating, trapping },
> implementation's choice.  Not { wrapping, saturating, trapping, nasal
> demons }.
>
>     As for casting... no.
>
>
> Then we should remove union from the language, because the current
> definition is inconsistent when combined with other aspects of the
> language.
Please guys, don't turn this into yet another thread about various forms
of unrelated UB.
The topic is 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--------------090203000600000903060309
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 07.12.2015 um 21:34 schrieb Myriachan:<br>
    <blockquote
      cite=3D"mid:a8f29891-7244-4f2b-9665-a26d541af4d3@isocpp.org"
      type=3D"cite">On Monday, December 7, 2015 at 12:15:38 PM UTC-8,
      Nicol Bolas 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">On Monday, December 7, 2015 at 2:47:59 PM UTC-5,
          Myriachan 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 idea I have is to take a middle approach:
              establish a couple of sequence points to avoid confusion.<br>
            </div>
          </blockquote>
          <div><br>
            That's essentially what the paper does. After all, it
            doesn't define order for everything; only for specific,
            cherry-picked cases.<br>
            <br>
            The difference is which cases it considers important.<br>
            <br>
            Personally, I prefer a standardized ordering guarantee for
            everything, not cherry picking. That only makes the language
            more complicated, as it encourages you to think it works the
            way you think it does... until it doesn't.<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">On Sunday, December 6, 2015 at 7:47:04 AM
              UTC-8, Nicol Bolas wrote:<br>
              <blockquote style=3D"margin:0px 0px 0px
                0.8ex;border-left:1px solid
                rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">A
                language becomes complex when it does not fit users'
                expectations. When that happens, you have to look up
                esoteric rules about how the language actually behaves.
                And then you have to later remember those rules when you
                write code.<br>
              </blockquote>
              <br>
              Now if only this applied to signed integer overflow and to
              unsigned types promoting to signed types...=C2=A0 Or to
              reinterpret_casting unrelated types...<br>
            </div>
          </blockquote>
          <div><br>
            Well, the signed/unsigned thing is about casting a wide net
            in terms of implementations. Some people really do need to
            work on non-two's complement machines.<br>
            <br>
          </div>
        </div>
      </blockquote>
      <div><br>
        Then define it as one of a set of { wrapping, saturating,
        trapping }, implementation's choice.=C2=A0 Not { wrapping,
        saturating, trapping, nasal demons }.<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>As for casting... no.<br>
          </div>
        </div>
      </blockquote>
      <div><br>
        Then we should remove union from the language, because the
        current definition is inconsistent when combined with other
        aspects of the language.<br>
      </div>
    </blockquote>
    Please guys, don't turn this into yet another thread about various
    forms of unrelated UB.<br>
    The topic is order of evaluation.<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------090203000600000903060309--

.

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

On 7 Dec 2015 19:58, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wrote:
>>
>> <snip>
>
>
> Then I guess we're going to have to agree to disagree then.
>
> I don't buy that the fact that something takes more words to describe
inherently makes it meaningfully more complex. I don't accept your idea
that changing the language to better fit users expectations is is somehow
hiding something from them.
>
> I don't even understand what "C++ code is being breaking when the rules
are changed, not the programs" is supposed to mean.
>
> I don't accept your assertion that changing code to match user's
expectations is being unfriendly to experienced users.

It is when you're violating the expectations of experienced users. Oh sure,
performance is not an observable attribute of the abstract machine. But it
is a major selling point of C++, and by preventing the compiler performing
CSE on loads and dependent subexpressions of the same expression where
there syntactically intervenes a possible store, you're forcing experienced
users to either do away with separate compilation and type erasure, or go
back to performing CSE by hand like in the dark ages.

People have developed their intuition of optimizer friendly code over
years, in some cases decades, and you want to throw that all away just for
the sake of marginally reducing beginner confusion?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<p dir=3D"ltr"><br>
On 7 Dec 2015 19:58, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmckesso=
n@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wrote:<br=
>
&gt;&gt;<br>
&gt;&gt; &lt;snip&gt;<br>
&gt;<br>
&gt;<br>
&gt; Then I guess we&#39;re going to have to agree to disagree then.<br>
&gt;<br>
&gt; I don&#39;t buy that the fact that something takes more words to descr=
ibe inherently makes it meaningfully more complex. I don&#39;t accept your =
idea that changing the language to better fit users expectations is is some=
how hiding something from them.<br>
&gt;<br>
&gt; I don&#39;t even understand what &quot;C++ code is being breaking when=
 the rules are changed, not the programs&quot; is supposed to mean.<br>
&gt;<br>
&gt; I don&#39;t accept your assertion that changing code to match user&#39=
;s expectations is being unfriendly to experienced users.</p>
<p dir=3D"ltr">It is when you&#39;re violating the expectations of experien=
ced users. Oh sure, performance is not an observable attribute of the abstr=
act machine. But it is a major selling point of C++, and by preventing the =
compiler performing CSE on loads and dependent subexpressions of the same e=
xpression where there syntactically intervenes a possible store, you&#39;re=
 forcing experienced users to either do away with separate compilation and =
type erasure, or go back to performing CSE by hand like in the dark ages. <=
/p>
<p dir=3D"ltr">People have developed their intuition of optimizer friendly =
code over years, in some cases decades, and you want to throw that all away=
 just for the sake of marginally reducing beginner confusion? <br>
</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ecb40337fed0526576abd--

.

On 12/7/2015 5:34 PM, Myriachan wrote:
> On Monday, December 7, 2015 at 12:15:38 PM UTC-8, Nicol Bolas wrote:
>
>     On Monday, December 7, 2015 at 2:47:59 PM UTC-5, Myriachan wrote:
>
>         The idea I have is to take a middle approach: establish a couple
>         of sequence points to avoid confusion.
>
>
>     That's essentially what the paper does. After all, it doesn't define
>     order for everything; only for specific, cherry-picked cases.
>
>     The difference is which cases it considers important.
>
>     Personally, I prefer a standardized ordering guarantee for
>     everything, not cherry picking. That only makes the language more
>     complicated, as it encourages you to think it works the way you
>     think it does... until it doesn't.
>
>         On Sunday, December 6, 2015 at 7:47:04 AM UTC-8, Nicol Bolas wrot=
e:
>
>             A language becomes complex when it does not fit users'
>             expectations. When that happens, you have to look up
>             esoteric rules about how the language actually behaves. And
>             then you have to later remember those rules when you write co=
de.
>
>
>         Now if only this applied to signed integer overflow and to
>         unsigned types promoting to signed types...  Or to
>         reinterpret_casting unrelated types...
>
>
>     Well, the signed/unsigned thing is about casting a wide net in terms
>     of implementations. Some people really do need to work on non-two's
>     complement machines.
>
>
> Then define it as one of a set of { wrapping, saturating, trapping },
> implementation's choice.  Not { wrapping, saturating, trapping, nasal
> demons }.
>
>     As for casting... no.
>
>
> Then we should remove union from the language, because the current
> definition is inconsistent when combined with other aspects of the langua=
ge.

As long as we are discussing C++, accessing an inactive member of a=20
union gives you undefined behavior. What's inconsistent about that?

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_897_1893567808.1449544870130
Content-Type: multipart/alternative;
 boundary="----=_Part_898_622759742.1449544870130"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=882:13:44=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> Left-to-right order is simple to describe. For binary operators, the left=
=20
> side is fully evaluated (i.e., all side effects are complete), the right=
=20
> side is fully evaluated, then the operation is fully evaluated.  For=20
> function calls, the function expression is fully evaluated, then each=20
> parameter is fully initialized in left-to-right order by its correspondin=
g=20
> fully-evaluated argument expression, with each initialization complete=20
> before the next one begins (so that an exception in argument evaluation=
=20
> neatly destructs the previously initialized parameters).  And so forth. =
=20
> You can go and look=20
>
> OK, doable, but still lots of words. Note that there are new redundancy=
=20
provide by the naive way: built-in operators vs. functions, and=20
initializers vs. function calls. For the purpose of the simplicity, they=20
should be merged in some way.
=20

> The fundamental problem with unspecified order of evaluation is that=20
> people write code that works as they expect because their implementation=
=20
> has the same mental model that they do.  Then one day the implementation=
=20
> changes, and all of a sudden the code doesn't work any more.=20
>
They please remove std::kill_dependency. It is far more subtle.
=20

> People, including experts, have been having the same misunderstandings an=
d=20
> making the same errors for literally decades.  (For example, how long did=
=20
> it take to figure out the f(new T, new T) issue?)
>
I don't think this should be an issue to experienced users. (I've invent my=
=20
own 'std::make_unique' years ago.) This should be quite easy to be realized=
=20
to those "experts".
=20

> The designers of Java and C# saw this as a problem to be fixed and chose=
=20
> left-to-right order.
>
From JLS:

It is recommended that code not rely crucially on this specification. Code=
=20
is usually clearer
when each expression contains at most one side effect, as its outermost=20
operation, and when
code does not depend on exactly which exception arises as a consequence of=
=20
the left-toright
evaluation of expressions.

It seems that they are afraid the users to know too much about it. This may=
=20
be reasonable since they are only somewhat anti-expert friendly, to reduce=
=20
the cost of manpower in some domains. Again not true for C++.

There is no good reason for not doing the same in C++, but as I have seen=
=20
> (also for decades), there are plenty of bad ones.
>
> There is at least one good reason: to keep newbies who don't bother to=20
learn some basic knowledge to do work serious away.=20

I still strongly suspect that anyone who can't solve these simple problems=
=20
by their own can be suitable as a professional programmer.


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=882:13:44=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">Left-to-right order is simple to describe. For binary operators,=
 the left side is fully evaluated (i.e., all side effects are complete), th=
e right side is fully evaluated, then the operation is fully evaluated.=C2=
=A0 For function calls, the function expression is fully evaluated, then ea=
ch parameter is fully initialized in left-to-right order by its correspondi=
ng fully-evaluated argument expression, with each initialization complete b=
efore the next one begins (so that an exception in argument evaluation neat=
ly destructs the previously initialized parameters).=C2=A0 And so forth.=C2=
=A0 You can go and look=C2=A0<br><br></div></blockquote><div>OK, doable, bu=
t still lots of words. Note that there are new redundancy provide by the na=
ive way: built-in operators vs. functions, and initializers vs. function ca=
lls. For the purpose of the simplicity, they should be merged in some way.<=
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">The fundamental problem with unspecified order of evaluation is that =
people write code that works as they expect because their implementation ha=
s the same mental model that they do.=C2=A0 Then one day the implementation=
 changes, and all of a sudden the code doesn&#39;t work any more.=C2=A0</di=
v></blockquote><div>They please remove std::kill_dependency. It is far more=
 subtle.<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 d=
ir=3D"ltr">People, including experts, have been having the same misundersta=
ndings and making the same errors for literally decades. =C2=A0(For example=
, how long did it take to figure out the <font face=3D"monospace, monospace=
">f(new T, new T)</font> issue?)</div></blockquote><div>I don&#39;t think t=
his should be an issue to experienced users. (I&#39;ve invent my own &#39;s=
td::make_unique&#39; years ago.) This should be quite easy to be realized t=
o those &quot;experts&quot;.<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">The designers of Java and C# saw this as a p=
roblem to be fixed and chose left-to-right order.</div></blockquote><div>Fr=
om JLS:<br><br><div style=3D"margin-left: 40px;">It is recommended that cod=
e not rely crucially on this specification. Code is usually clearer<br>when=
 each expression contains at most one side effect, as its outermost operati=
on, and when<br>code does not depend on exactly which exception arises as a=
 consequence of the left-toright<br>evaluation of expressions.<br></div><br=
>It seems that they are afraid the users to know too much about it. This ma=
y be reasonable since they are only somewhat anti-expert friendly, to reduc=
e the cost of manpower in some domains. Again not true for C++.<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">There is no=
 good reason for not doing the same in C++, but as I have seen (also for de=
cades), there are plenty of bad ones.</div><div><br></div></blockquote><div=
>There is at least one good reason: to keep newbies who don&#39;t bother to=
 learn some basic knowledge to do work serious away. <br><br>I still strong=
ly suspect that anyone who can&#39;t solve these simple problems by their o=
wn can be suitable as a professional programmer.<br><br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_898_622759742.1449544870130--
------=_Part_897_1893567808.1449544870130--

.

------=_Part_5750_2042203206.1449546557876
Content-Type: multipart/alternative;
 boundary="----=_Part_5751_1725176515.1449546557876"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=883:47:59=EF=BC=8CMyriachan=E5=86=99=E9=81=93=EF=BC=9A
>
> The idea I have is to take a middle approach: establish a couple of=20
> sequence points to avoid confusion.
>
> I think that it's fine to say that function parameters are evaluated in a=
n=20
> arbitrary order, as are subexpressions in most binary operators (e.g.=20
> meow() + kitty() can call the functions in either order).  However, there=
=20
> are a couple of places where the binary operator needs to have a defined=
=20
> order, in my opinion:
>
> first, second    (already sequenced)
> first ? second : second    (already sequenced)
> first.*second
> first->*second
> first(second...)
> first << second    (when overloaded only?)
> first >> second    (when overloaded only?)
>
> It's really confusing that (new T)->Function(Meow()); can call Meow befor=
e=20
> T::operator new and T::T.
>
> Something like CWG222 <http://wg21.cmeerw.net/cwg/issue222>?=20

Sequenced points have been removed. They are replaced by the family of *seq=
uenced=20
before *relationships. Do you want to pull them back and maintain both, as=
=20
ISO C do?
=20

>
> On Sunday, December 6, 2015 at 7:47:04 AM UTC-8, Nicol Bolas wrote:
>
>> A language becomes complex when it does not fit users' expectations. Whe=
n=20
>> that happens, you have to look up esoteric rules about how the language=
=20
>> actually behaves. And then you have to later remember those rules when y=
ou=20
>> write code.
>>
>
> Now if only this applied to signed integer overflow and to unsigned types=
=20
> promoting to signed types...  Or to reinterpret_casting unrelated types..=
..
>
>
> Melissa
>

The type system on fundamental types are another domain of problems, but=20
I'd say here: I am unsatisfied.

The language is too weak and leaky on abstraction.

   - It has nothing about fine-grained numerical hierarchy, like numerical=
=20
   tower <https://en.wikipedia.org/wiki/Numerical_tower>s. "Rank" is=20
   hard-coded in specific conversion rules, providing a lot of pain to user=
s.
   - Representation is limited even if users don't care. (To be fair, this=
=20
   is not concerned only with these types. It is a more serious problem in=
=20
   general: the oversold object model and (again) "expectation", even ABI=
=20
   compatibility would often be a joke in reality.)
   - It has no "infinite" precision numbers. (Put on WG21 wish list by BS=
=20
   decades ago?)
   - Even the UB on overflow is sold as a bundle to signedness. I have no=
=20
   mean to get Unsigned<32, UBOnOverflow> or Int<32, Wrapped> easily. (At=
=20
   least specifying UB is not possible without core language change.)
  =20
I complain it here, because the situation is similar: the language rules is=
=20
already disabled and broken, not so powerful as sold to most users. Someone=
=20
even wants to limit the current expresiveness, just because they don't want=
=20
to urge other people to learn. *Ridiculous.*

(Oh, you need only a better C? Then go to use C.)

Note this point is not about the design of default policy on some features.=
=20
The latter is still valuable to talk about.


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=8C UTC+8=E4=B8=8A=E5=8D=883:47:59=EF=BC=8CMyriachan=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 =
idea I have is to take a middle approach: establish a couple of sequence po=
ints to avoid confusion.<br><br>I think that it&#39;s fine to say that func=
tion parameters are evaluated in an arbitrary order, as are subexpressions =
in most binary operators (e.g. meow() + kitty() can call the functions in e=
ither order).=C2=A0 However, there are a couple of places where the binary =
operator needs to have a defined order, in my opinion:<br><br>first, second=
=C2=A0=C2=A0=C2=A0 (already sequenced)<br>first ? second : second=C2=A0 =C2=
=A0 (already sequenced)<br>first.*second<br>first-&gt;*second<br>first(seco=
nd...)<br>first &lt;&lt; second=C2=A0=C2=A0=C2=A0 (when overloaded only?)<b=
r>first &gt;&gt; second=C2=A0=C2=A0=C2=A0 (when overloaded only?)<br><br>It=
&#39;s really confusing that (new T)-&gt;Function(Meow()); can call Meow be=
fore T::operator new and T::T.<br><br></div></blockquote><div>Something lik=
e <a href=3D"http://wg21.cmeerw.net/cwg/issue222">CWG222</a>? <br></div><di=
v><br>Sequenced points have been removed. They are replaced by the family o=
f <i>sequenced before </i>relationships. Do you want to pull them back and =
maintain both, as ISO C do?<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"><br>On Sunday, December 6, 2015 at 7:47:04 AM=
 UTC-8, Nicol Bolas wrote:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_qu=
ote">A
 language becomes complex when it does not fit users&#39; expectations. Whe=
n
 that happens, you have to look up esoteric rules about how the language
 actually behaves. And then you have to later remember those rules when=20
you write code.<br></blockquote><br>Now if only this applied to signed inte=
ger overflow and to unsigned types promoting to signed types...=C2=A0 Or to=
 reinterpret_casting unrelated types...<br><br><br>Melissa<br></div></block=
quote><div><br>The type system on fundamental types are another domain of p=
roblems, but I&#39;d say here: I am unsatisfied.<br><br>The language is too=
 weak and leaky on abstraction.<br><ul><li>It has nothing about <span class=
=3D"op_dict3_font24 op_dict3_marginRight">fine-grained numerical hierarchy,=
 </span>like <a href=3D"https://en.wikipedia.org/wiki/Numerical_tower">nume=
rical tower</a>s. &quot;Rank&quot; is hard-coded in specific conversion rul=
es, providing a lot of pain to users.</li><li>Representation is limited eve=
n if users don&#39;t care. (To be fair, this is not concerned only with the=
se types. It is a more serious problem in general: the oversold object mode=
l and (again) &quot;expectation&quot;, even ABI compatibility would often b=
e a joke in reality.)<br></li><li>It has no &quot;infinite&quot; precision =
numbers. (Put on WG21 wish list by BS decades ago?)<br></li><li>Even the UB=
 on overflow is sold as a bundle to signedness. I have no mean to get Unsig=
ned&lt;32, UBOnOverflow&gt; or Int&lt;32, Wrapped&gt; easily. (At least spe=
cifying UB is not possible without core language change.)<br></li></ul>I co=
mplain it here, because the situation is similar: the language rules is alr=
eady disabled and broken, not so powerful as sold to most users. Someone ev=
en wants to limit the current expresiveness, just because they don&#39;t wa=
nt to urge other people to learn. <b>Ridiculous.</b><br><br>(Oh, you need o=
nly a better C? Then go to use C.)<br><br>Note this point is not about the =
design of default policy on some features. The latter is still valuable to =
talk about.<br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5751_1725176515.1449546557876--
------=_Part_5750_2042203206.1449546557876--

.

------=_Part_5775_738261059.1449547999261
Content-Type: multipart/alternative;
 boundary="----=_Part_5776_1575966272.1449547999261"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=883:58:10=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wrote:
>
>> <snip>
>>
>
> Then I guess we're going to have to agree to disagree then.
>
> I don't buy that the fact that something takes more words to describe=20
> inherently makes it meaningfully more complex. I don't accept your idea=
=20
> that changing the language to better fit users expectations is is somehow=
=20
> hiding something from them.
>
> This is not meaningfully more complex. Nothing is simpler than everything=
..=20
"Unsequenced" is simpler than left-to-right. No changing is simpler than=20
changing. That's all about it. Anyway, simplicity is not the principle=20
reason to change, in general. "Not simple" is even not my first reason to=
=20
be against the change.

(Please don't use metaphor about natural languages as a valid reason.=20
Familiarity is not the purpose. Do those who can't be adapt to non-LTR=20
order have "order" in mind? I don't think so. They deserve to think more.=
=20
And what about RTL languages?)=20
=20

> I don't even understand what "C++ code is being breaking when the rules=
=20
> are changed, not the programs" is supposed to mean.
>
> Go to model the program using any formal methods. Find the differences.
=20

> I don't accept your assertion that changing code to match user's=20
> expectations is being unfriendly to experienced users. I do not buy into=
=20
> your belief that code written with the expectation of this behavior is a=
=20
> priori "crap" even if the standard made it well-defined.
>
> It seems that we don't have the meaning of "experienced users".in=20
consensus at first.

I do not find any of your arguments to be the slightest bit convincing, but=
=20
> it's clear that explaining why will not move this discussion further.
>
> However, there is one point I would specifically like to respond to:
>
> They would be in pain again when they bit by UB with old implementations.=
=20
>> Please evaluate the probability seriously.
>>
>
> Very well; let's "evaluate the probability seriously".
>
> Jump ahead 2 years. C++17 incorporates these ordering rules.
>
Are you sure it will be shipped with C++17?
=20

> Some people start writing code against C++17 that deliberately relies on=
=20
> these rules (as opposed to accidentally relying on them).
>
> Of course, since they're writing C++17 code that is meant for a C++17=20
> compiler, they will almost certainly also be writing code that relies on=
=20
> *other* C++17 features.
>
=20

> Maybe they're using multiple-return-values through tuples. Maybe concepts=
=20
> was adopted into C++17. Maybe they'll be using the many new standard=20
> library objects adopted into C++17.
>
> None of these features will compile on "old implementations". Therefore,=
=20
> the only time the situation you describe could be a problem is if someone=
=20
> has written code that relies on exactly and *only *this one feature of=20
> C++17*.*
>
> What reason do you have to believe that this would be a *likely*=20
> eventuality? Could it bite someone? Sure. Is that "probable"? No.
>
Not every pieces of code will. Copying and pasting based on blocks of code=
=20
is not rare.

And they would *likely* to backport their code for old implementations, and=
=20
occasionally forget the dependency on such subtle changes of rules.

If luckily enough, boom!


 =20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=883:58:10=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 Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wro=
te:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">&lt;snip&gt;<br></=
blockquote><div><br>Then I guess we&#39;re going to have to agree to disagr=
ee then.<br><br>I don&#39;t buy that the fact that something takes more wor=
ds to describe inherently makes it meaningfully more complex. I don&#39;t a=
ccept your idea that changing the language to better fit users expectations=
 is is somehow hiding something from them.<br><br></div></div></blockquote>=
<div>This is not meaningfully more complex. Nothing is simpler than everyth=
ing. &quot;Unsequenced&quot; is simpler than left-to-right. No changing is =
simpler than changing. That&#39;s all about it. Anyway, simplicity is not t=
he principle reason to change, in general. &quot;Not simple&quot; is even n=
ot my first reason to be against the change.<br><br>(Please don&#39;t use m=
etaphor about natural languages as a valid reason.=20
Familiarity is not the purpose. Do those who can&#39;t be adapt to non-LTR=
=20
order have &quot;order&quot; in mind? I don&#39;t think so. They deserve to=
 think=20
more. And what about RTL languages?) <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>I don&#39;t even understa=
nd what &quot;C++ code is being breaking when the rules are changed, not th=
e programs&quot; is supposed to mean.<br><br></div></div></blockquote><div>=
Go to model the program using any formal methods. Find the differences.<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>I don&#39;t accept your assertion that changing code to match user&=
#39;s expectations is being unfriendly to experienced users. I do not buy i=
nto your belief that code written with the expectation of this behavior is =
a priori &quot;crap&quot; even if the standard made it well-defined.<br><br=
></div></div></blockquote><div>It seems that we don&#39;t have the meaning =
of &quot;experienced users&quot;.in consensus at first.<br><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>I do not find =
any of your arguments to be the slightest bit convincing, but it&#39;s clea=
r that explaining why will not move this discussion further.<br><br>However=
, there is one point I would specifically like to respond to:<br><br><block=
quote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex" class=3D"gmail_quote">They would be in pain again whe=
n they bit by UB with old implementations. Please evaluate the probability =
seriously.<br></blockquote></div><br>Very well; let&#39;s &quot;evaluate th=
e probability seriously&quot;.<br><br>Jump ahead 2 years. C++17 incorporate=
s these ordering rules.</div></blockquote><div>Are you sure it will be ship=
ped with C++17?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">Some people start writing code against C++17 that deliber=
ately relies on these rules (as opposed to accidentally relying on them).<b=
r><br>Of course, since they&#39;re writing C++17 code that is meant for a C=
++17 compiler, they will almost certainly also be writing code that relies =
on <i>other</i> C++17 features.</div></blockquote><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Maybe they&#39;re usi=
ng multiple-return-values through tuples. Maybe concepts was adopted into C=
++17. Maybe they&#39;ll be using the many new standard library objects adop=
ted into C++17.<br><br>None of these features will compile on &quot;old imp=
lementations&quot;. Therefore, the only time the situation you describe cou=
ld be a problem is if someone has written code that relies on exactly and <=
i>only </i>this one feature of C++17<i>.</i><br><i><br></i>What reason do y=
ou have to believe that this would be a <i>likely</i> eventuality? Could it=
 bite someone? Sure. Is that &quot;probable&quot;? No.<br></div></blockquot=
e><div>Not every pieces of code will. Copying and pasting based on blocks o=
f code is not rare.<br><br>And they would <i>likely</i> to backport their c=
ode for old implementations, and occasionally forget the dependency on such=
 subtle changes of rules.<br><br>If luckily enough, boom!<br><br><br>=C2=A0=
 <br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5776_1575966272.1449547999261--
------=_Part_5775_738261059.1449547999261--

.

On Monday 07 December 2015 19:49:17 FrankHB1989 wrote:
>    - Even the UB on overflow is sold as a bundle to signedness. I have no
>    mean to get Unsigned<32, UBOnOverflow> or Int<32, Wrapped> easily. (At
>    least specifying UB is not possible without core language change.)

Why can't you get that easily?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5966_2145159751.1449548571803
Content-Type: multipart/alternative;
 boundary="----=_Part_5967_1538204155.1449548571803"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8812:14:38=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Monday 07 December 2015 19:49:17 FrankHB1989 wrote:=20
> >    - Even the UB on overflow is sold as a bundle to signedness. I have=
=20
> no=20
> >    mean to get Unsigned<32, UBOnOverflow> or Int<32, Wrapped> easily.=
=20
> (At=20
> >    least specifying UB is not possible without core language change.)=
=20
>
> Why can't you get that easily?=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
> =20
How can you do them easily?

For example, 'using specific_uint =3D uint32;' is easy. But I don't know ho=
w=20
to inform the compiler assuming 'specific_uint' never overflow. Should I=20
implement the language myself (to provide an extension)?
=20
And I can implement modular arithmetic operations by defining a wrapper=20
class to a integer type. It is certainly not easy as an *alias-declaration*=
..

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=8C UTC+8=E4=B8=8B=E5=8D=8812:14:38=EF=BC=8CThiago Macieira=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;">On Monday 07 De=
cember 2015 19:49:17 FrankHB1989 wrote:
<br>&gt; =C2=A0 =C2=A0- Even the UB on overflow is sold as a bundle to sign=
edness. I have no=20
<br>&gt; =C2=A0 =C2=A0mean to get Unsigned&lt;32, UBOnOverflow&gt; or Int&l=
t;32, Wrapped&gt; easily. (At=20
<br>&gt; =C2=A0 =C2=A0least specifying UB is not possible without core lang=
uage change.)
<br>
<br>Why can&#39;t you get that easily?
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46snt=
z\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;">maciei=
ra.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1Dowztw=
AHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google=
..com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo=
5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote><div>=C2=A0</div><div>How can you do them easily?<br><br>F=
or example, &#39;using specific_uint =3D uint32;&#39; is easy. But I don&#3=
9;t know how to inform the compiler assuming &#39;specific_uint&#39; never =
overflow. Should I implement the language myself (to provide an extension)?=
<br></div><div>=C2=A0<br>And I can implement modular arithmetic operations =
by defining a wrapper class to a integer type. It is certainly not easy as =
an <i>alias-declaration</i>.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5967_1538204155.1449548571803--
------=_Part_5966_2145159751.1449548571803--

.

On Monday 07 December 2015 20:22:51 FrankHB1989 wrote:
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8B=E5=8D=8812:14:38=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
> > On Monday 07 December 2015 19:49:17 FrankHB1989 wrote:
> > >    - Even the UB on overflow is sold as a bundle to signedness. I hav=
e
> > no
> > >    mean to get Unsigned<32, UBOnOverflow> or Int<32, Wrapped> easily.
> > (At
> > >    least specifying UB is not possible without core language change.)
> >=20
> > Why can't you get that easily?
>=20
> How can you do them easily?

Write your own class. If necessary, use assembly or compiler intrinsics.

> For example, 'using specific_uint =3D uint32;' is easy. But I don't know =
how
> to inform the compiler assuming 'specific_uint' never overflow. Should I
> implement the language myself (to provide an extension)?

Yes. That's how everything works in the language: what isn't provided by th=
e=20
compiler built-in types can be provided by writing the proper classes. The=
=20
compiler can always provide extended types not specified by the standard, l=
ike=20
__int128, __float128, like long long was before C++11.

> And I can implement modular arithmetic operations by defining a wrapper
> class to a integer type. It is certainly not easy as an *alias-declaratio=
n*.

I thought you were asking how to write that class.

You want the compiler and the language to provide all the functionality for=
=20
you, so  you can simply write an alias. Why can't you do some heavy-lifting=
=20
yourself?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_2053_1511623905.1449551046831
Content-Type: multipart/alternative;
 boundary="----=_Part_2054_521472780.1449551046831"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8812:44:57=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Monday 07 December 2015 20:22:51 FrankHB1989 wrote:=20
> > =E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=
 UTC+8=E4=B8=8B=E5=8D=8812:14:38=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=
=EF=BC=9A=20
> > > On Monday 07 December 2015 19:49:17 FrankHB1989 wrote:=20
> > > >    - Even the UB on overflow is sold as a bundle to signedness. I=
=20
> have=20
> > > no=20
> > > >    mean to get Unsigned<32, UBOnOverflow> or Int<32, Wrapped>=20
> easily.=20
> > > (At=20
> > > >    least specifying UB is not possible without core language=20
> change.)=20
> > >=20
> > > Why can't you get that easily?=20
> >=20
> > How can you do them easily?=20
>
> Write your own class. If necessary, use assembly or compiler intrinsics.=
=20
>
> lol, it is harder.

> For example, 'using specific_uint =3D uint32;' is easy. But I don't know=
=20
> how=20
> > to inform the compiler assuming 'specific_uint' never overflow. Should =
I=20
> > implement the language myself (to provide an extension)?=20
>
> Yes. That's how everything works in the language: what isn't provided by=
=20
> the=20
> compiler built-in types can be provided by writing the proper classes. Th=
e=20
> compiler can always provide extended types not specified by the standard,=
=20
> like=20
> __int128, __float128, like long long was before C++11.=20
>
> However, is it better to be portable? Though it is not like long long,=20
which have been supported by many vendors for years before being=20
standardized.

(Until who write proposals...)
=20

> > And I can implement modular arithmetic operations by defining a wrapper=
=20
> > class to a integer type. It is certainly not easy as an=20
> *alias-declaration*.=20
>
> I thought you were asking how to write that class.=20
>
> You want the compiler and the language to provide all the functionality=
=20
> for=20
> you, so  you can simply write an alias. Why can't you do some=20
> heavy-lifting=20
> yourself?=20
>
> If features are worth being used by many users, it should better in the=
=20
specification. Such daily used feature should not only available on=20
specific dialects.
Or perhaps better to invent new one and forget by people years later ...=20
eventually the features should be in the major industrial languages,=20
hopefully.

These features are not randomly picked. The current design of "signed=20
integer overflow is UB but unsigned integer never overflow" still sounds a=
=20
WTF to many C and C++ users. And I've see there are people who insists=20
signed integers over unsigned integers in general using "signed integer is=
=20
more friendly to be optimized because overflow is UB" as an excuse. So why=
=20
unsigned integers deserve to be worse? This makes me to realize the lack of=
=20
these orthogonality is a defect. It is inherited from C, but perhaps C++=20
can solve it more graceful.


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8812:44:57=EF=BC=8CThiago Maciei=
ra=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 Monday 07 December 2015 20:22:51 FrankHB1989 wrote:
<br>&gt; =E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=8C UTC+8=E4=B8=8B=E5=8D=8812:14:38=EF=BC=8CThiago Macieira=E5=86=99=E9=
=81=93=EF=BC=9A
<br>&gt; &gt; On Monday 07 December 2015 19:49:17 FrankHB1989 wrote:
<br>&gt; &gt; &gt; =C2=A0 =C2=A0- Even the UB on overflow is sold as a bund=
le to signedness. I have
<br>&gt; &gt; no
<br>&gt; &gt; &gt; =C2=A0 =C2=A0mean to get Unsigned&lt;32, UBOnOverflow&gt=
; or Int&lt;32, Wrapped&gt; easily.
<br>&gt; &gt; (At
<br>&gt; &gt; &gt; =C2=A0 =C2=A0least specifying UB is not possible without=
 core language change.)
<br>&gt; &gt;=20
<br>&gt; &gt; Why can&#39;t you get that easily?
<br>&gt;=20
<br>&gt; How can you do them easily?
<br>
<br>Write your own class. If necessary, use assembly or compiler intrinsics=
..
<br>
<br></blockquote><div>lol, it is harder.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">&gt; For example, &#39;using specific_uint =3D uint=
32;&#39; is easy. But I don&#39;t know how
<br>&gt; to inform the compiler assuming &#39;specific_uint&#39; never over=
flow. Should I
<br>&gt; implement the language myself (to provide an extension)?
<br>
<br>Yes. That&#39;s how everything works in the language: what isn&#39;t pr=
ovided by the=20
<br>compiler built-in types can be provided by writing the proper classes. =
The=20
<br>compiler can always provide extended types not specified by the standar=
d, like=20
<br>__int128, __float128, like long long was before C++11.
<br>
<br></blockquote><div>However, is it better to be portable? Though it is no=
t like long long, which have been supported by many vendors for years befor=
e being standardized.<br><br>(Until who write proposals...)<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;">&gt; And I can implement m=
odular arithmetic operations by defining a wrapper
<br>&gt; class to a integer type. It is certainly not easy as an *alias-dec=
laration*.
<br>
<br>I thought you were asking how to write that class.
<br>
<br>You want the compiler and the language to provide all the functionality=
 for=20
<br>you, so =C2=A0you can simply write an alias. Why can&#39;t you do some =
heavy-lifting=20
<br>yourself?
<br>
<br></blockquote><div>If features are worth being used by many users, it sh=
ould better in the=20
specification. Such daily used feature should not only available on=20
specific dialects.<br>Or perhaps better to invent new one and forget by peo=
ple years later ... eventually the features should be in the major industri=
al languages, hopefully.<br><br>These features are not randomly picked. The=
 current design of &quot;signed integer overflow is UB but unsigned integer=
 never overflow&quot; still sounds a WTF to many C and C++ users. And I&#39=
;ve see there are people who insists signed integers over unsigned integers=
 in general using &quot;signed integer is more friendly to be optimized bec=
ause overflow is UB&quot; as an excuse. So why unsigned integers deserve to=
 be worse? This makes me to realize the lack of these orthogonality is a de=
fect. It is inherited from C, but perhaps C++ can solve it more graceful.<b=
r><br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2054_521472780.1449551046831--
------=_Part_2053_1511623905.1449551046831--

.

On Monday 07 December 2015 21:04:06 FrankHB1989 wrote:
> > Yes. That's how everything works in the language: what isn't provided by
> > the
> > compiler built-in types can be provided by writing the proper classes. The
> > compiler can always provide extended types not specified by the standard,
> > like
> > __int128, __float128, like long long was before C++11.
> >
> However, is it better to be portable? Though it is not like long long,
> which have been supported by many vendors for years before being
> standardized.

It would be better, indeed. But that assumes that all platforms could support
it. On some, it might be very expensive to provide saturation or traps.

But being portable does not require being a primitive type in the language. It
can be a class, implemented entirely in library code. In fact, with the GCC
and Clang __builtin_{add,sub,mul}_overflow intrinsics, it should be possible to
do just that.

> > > And I can implement modular arithmetic operations by defining a wrapper
> > > class to a integer type. It is certainly not easy as an
> >
> > *alias-declaration*.
> >
> > I thought you were asking how to write that class.
> >
> > You want the compiler and the language to provide all the functionality
> > for
> > you, so  you can simply write an alias. Why can't you do some
> > heavy-lifting
> > yourself?
> >
> If features are worth being used by many users, it should better in the
> specification. Such daily used feature should not only available on
> specific dialects.

I disagree. Neither the language nor the Standard Library will ever be
exhaustive. And besides, this feature is *definitely* not daily used. I cannot
remember the last time I've needed saturation. As for overflow detection, I've
needed it recently, but not often.

And finally, it does not need to be in the core language, as I explained above.

> These features are not randomly picked. The current design of "signed
> integer overflow is UB but unsigned integer never overflow" still sounds a
> WTF to many C and C++ users. And I've see there are people who insists
> signed integers over unsigned integers in general using "signed integer is
> more friendly to be optimized because overflow is UB" as an excuse. So why
> unsigned integers deserve to be worse? This makes me to realize the lack of
> these orthogonality is a defect. It is inherited from C, but perhaps C++
> can solve it more graceful.

With classes.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Monday 07 December 2015 11:47:58 Myriachan wrote:
> first, second    (already sequenced)
> first ? second : second    (already sequenced)
> first.*second
> first->*second
> first(second...)
> first << second    (when overloaded only?)
> first >> second    (when overloaded only?)

When it's overloaded, it's a function call:
 operator<<(second...);
 operator>>(second...);
 operator->*(second...);

In any case, I don't think that's a good explanation. What if one of the two
sides is a very complex expression? Why shouldn't the compiler be allowed to
optimise? The example is your case:

> It's really confusing that (new T)->Function(Meow()); can call Meow before
> T::operator new and T::T.

I probably would never think about it unless prompted to, but if asked, I'd
have to say there's no good reason why shouldn't evaluate Meow() first. For
example, the code were:

 (new T)->Function(Meow(some_var));

and some_var is a local variable not used anymore in this scope. It's an easy
optimisation for the compiler to call Meow(some_var) first, then discard the
variable. If the compiler is forced to call operator new() first, it may need
to spill the variable to the stack first, causing a performance penalty.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 8 December 2015 at 09:29, Thiago Macieira <thiago@macieira.org> wrote:
>> It's really confusing that (new T)->Function(Meow()); can call Meow before
>> T::operator new and T::T.
> I probably would never think about it unless prompted to, but if asked, I'd
> have to say there's no good reason why shouldn't evaluate Meow() first. For


I can. If the initialization and/or the operator-> (in case new isn't used but a
temporary object is initialized) establish a context under which
Meow() is expected
to run, it's rather important that Meow() is not run outside that
context. Single-shot
locks come to mind, and there are other facilities like 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tuesday 08 December 2015 09:34:21 Ville Voutilainen wrote:
> On 8 December 2015 at 09:29, Thiago Macieira <thiago@macieira.org> wrote:
> >> It's really confusing that (new T)->Function(Meow()); can call Meow
> >> before
> >> T::operator new and T::T.
> >
> > I probably would never think about it unless prompted to, but if asked,
> > I'd
> > have to say there's no good reason why shouldn't evaluate Meow() first.
> > For
>
> I can. If the initialization and/or the operator-> (in case new isn't used
> but a temporary object is initialized) establish a context under which
> Meow() is expected
> to run, it's rather important that Meow() is not run outside that
> context. Single-shot
> locks come to mind, and there are other facilities like that.

My point was that, when reading that line, I would be able to say, "sure, it
can run that before this".

I understand that you may write code as you described. But the flip side is
also entirely possible: someone may write code that relies on Meow() being
called before T::operator new().

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 8 December 2015 at 09:39, Thiago Macieira <thiago@macieira.org> wrote:
>> I can. If the initialization and/or the operator-> (in case new isn't used
>> but a temporary object is initialized) establish a context under which
>> Meow() is expected
>> to run, it's rather important that Meow() is not run outside that
>> context. Single-shot
>> locks come to mind, and there are other facilities like that.
>
> My point was that, when reading that line, I would be able to say, "sure, it
> can run that before this".
>
> I understand that you may write code as you described. But the flip side is
> also entirely possible: someone may write code that relies on Meow() being
> called before T::operator new().


Granted, that would be imaginable. Currently neither I nor such users can do
such things since there is no order specified. :)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_6031_1369691005.1449566945514
Content-Type: multipart/alternative;
 boundary="----=_Part_6032_1787737823.1449566945520"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=883:27:05=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Monday 07 December 2015 21:04:06 FrankHB1989 wrote:=20
> > > Yes. That's how everything works in the language: what isn't provided=
=20
> by=20
> > > the=20
> > > compiler built-in types can be provided by writing the proper classes=
..=20
> The=20
> > > compiler can always provide extended types not specified by the=20
> standard,=20
> > > like=20
> > > __int128, __float128, like long long was before C++11.=20
> > >=20
> > However, is it better to be portable? Though it is not like long long,=
=20
> > which have been supported by many vendors for years before being=20
> > standardized.=20
>
> It would be better, indeed. But that assumes that all platforms could=20
> support=20
> it. On some, it might be very expensive to provide saturation or traps.=
=20
>
> I agree that it can be expensive.
However, we have some useful features with overhead depending on=20
implementation. For example, exception handling nowadays still not always=
=20
meets the zero overhead principle. There is trade off.
And allowing UB on unsigned integer is loosing the restriction. At least=20
this feature will introduce no more overhead. There is even no more work=20
required to do for compiler backend to support it, because the current=20
unsigned integers are also conforming.

But being portable does not require being a primitive type in the language.=
=20
> It=20
> can be a class, implemented entirely in library code. In fact, with the=
=20
> GCC=20
> and Clang __builtin_{add,sub,mul}_overflow intrinsics, it should be=20
> possible to=20
> do just that.=20
>
> The "portable" way is in the sense of standard, e.g. UB is "not portable"=
..=20
Even "__builtin_" can be hopefully portable between GCC and Clang, using of=
=20
identifier beginning with double underscore is definitely not portable C++.=
=20
Though in practice they can  be wrapped as macros.=20

> > > And I can implement modular arithmetic operations by defining a=20
> wrapper=20
> > > > class to a integer type. It is certainly not easy as an=20
> > >=20
> > > *alias-declaration*.=20
> > >=20
> > > I thought you were asking how to write that class.=20
> > >=20
> > > You want the compiler and the language to provide all the=20
> functionality=20
> > > for=20
> > > you, so  you can simply write an alias. Why can't you do some=20
> > > heavy-lifting=20
> > > yourself?=20
> > >=20
> > If features are worth being used by many users, it should better in the=
=20
> > specification. Such daily used feature should not only available on=20
> > specific dialects.=20
>
> I disagree. Neither the language nor the Standard Library will ever be=20
> exhaustive. And besides, this feature is *definitely* not daily used. I=
=20
> cannot=20
> remember the last time I've needed saturation. As for overflow detection,=
=20
> I've=20
> needed it recently, but not often.=20
>
> Specific demands on UB or not is not daily used. But integer itself is.

In pseudo code:
template<bool _Signed, _OverflowStrategy _O, size_t _Size, _Rep =3D=20
_Two_s_complement>
using __Integer =3D __builtin_int_type(_Signed, _O, _Size, _Rep);

using int =3D __Integer<true, _Undefined, _Target_int_size>;
using long =3D __Integer<true, _Undefined, _Target_long_size>;
using unsigned =3D __Integer<false, _Never_Overflow_and_Wrapped,=20
_Target_unsigned_size>;

Only signedness can be specified directly be user. (The exact sized integer=
=20
is optionally provided by the standard library.) All others are not=20
specified by the user, but the policies do exist for every implementation=
=20
(though some of them might have been partial evaluated=20
<https://en.wikipedia.org/wiki/Partial_evaluation>, i.e. fixed at build=20
time of the toolchain). In this sense you *are *daily using them, even if=
=20
you don't care the concrete choice mostly.

I'll be appreciative if standard library can provide such interface with=20
possible to specify the strategy on unsigned integers (so I have=20
opportunity to get more optimized code), even if other combinations are=20
conditionally-supported. At least the interface can be clearer to reflect=
=20
my intent without verbose comments each time I defined an alias.
=20

> And finally, it does not need to be in the core language, as I explained=
=20
> above.=20
>
> This need to be a core change if portability is needed and standard=20
library does not provide such interface.
=20

> > These features are not randomly picked. The current design of "signed=
=20
> > integer overflow is UB but unsigned integer never overflow" still sound=
s=20
> a=20
> > WTF to many C and C++ users. And I've see there are people who insists=
=20
> > signed integers over unsigned integers in general using "signed integer=
=20
> is=20
> > more friendly to be optimized because overflow is UB" as an excuse. So=
=20
> why=20
> > unsigned integers deserve to be worse? This makes me to realize the lac=
k=20
> of=20
> > these orthogonality is a defect. It is inherited from C, but perhaps C+=
+=20
> > can solve it more graceful.=20
>
> With classes.=20
>
> With templates.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=883:27:05=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;">On=
 Monday 07 December 2015 21:04:06 FrankHB1989 wrote:
<br>&gt; &gt; Yes. That&#39;s how everything works in the language: what is=
n&#39;t provided by
<br>&gt; &gt; the
<br>&gt; &gt; compiler built-in types can be provided by writing the proper=
 classes. The
<br>&gt; &gt; compiler can always provide extended types not specified by t=
he standard,
<br>&gt; &gt; like
<br>&gt; &gt; __int128, __float128, like long long was before C++11.
<br>&gt; &gt;=20
<br>&gt; However, is it better to be portable? Though it is not like long l=
ong,
<br>&gt; which have been supported by many vendors for years before being
<br>&gt; standardized.
<br>
<br>It would be better, indeed. But that assumes that all platforms could s=
upport=20
<br>it. On some, it might be very expensive to provide saturation or traps.
<br>
<br></blockquote><div>I agree that it can be expensive.<br>However, we have=
 some useful features with overhead depending on implementation. For exampl=
e, exception handling nowadays still not always meets the zero overhead pri=
nciple. There is trade off.<br>And allowing UB on unsigned integer is loosi=
ng the restriction. At least this feature will introduce no more overhead. =
There is even no more work required to do for compiler backend to support i=
t, because the current unsigned integers are also conforming.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">But being portable does not re=
quire being a primitive type in the language. It=20
<br>can be a class, implemented entirely in library code. In fact, with the=
 GCC=20
<br>and Clang __builtin_{add,sub,mul}_<wbr>overflow intrinsics, it should b=
e possible to=20
<br>do just that.
<br>
<br></blockquote><div>The &quot;portable&quot; way is in the sense of stand=
ard, e.g. UB is &quot;not portable&quot;. Even &quot;__builtin_&quot; can b=
e hopefully portable between GCC and Clang, using of identifier beginning w=
ith double underscore is definitely not portable C++. Though in practice th=
ey can=C2=A0 be wrapped as macros. <br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">&gt; &gt; &gt; And I can implement modular arithmetic op=
erations by defining a wrapper
<br>&gt; &gt; &gt; class to a integer type. It is certainly not easy as an
<br>&gt; &gt;=20
<br>&gt; &gt; *alias-declaration*.
<br>&gt; &gt;=20
<br>&gt; &gt; I thought you were asking how to write that class.
<br>&gt; &gt;=20
<br>&gt; &gt; You want the compiler and the language to provide all the fun=
ctionality
<br>&gt; &gt; for
<br>&gt; &gt; you, so =C2=A0you can simply write an alias. Why can&#39;t yo=
u do some
<br>&gt; &gt; heavy-lifting
<br>&gt; &gt; yourself?
<br>&gt; &gt;=20
<br>&gt; If features are worth being used by many users, it should better i=
n the
<br>&gt; specification. Such daily used feature should not only available o=
n
<br>&gt; specific dialects.
<br>
<br>I disagree. Neither the language nor the Standard Library will ever be=
=20
<br>exhaustive. And besides, this feature is *definitely* not daily used. I=
 cannot=20
<br>remember the last time I&#39;ve needed saturation. As for overflow dete=
ction, I&#39;ve=20
<br>needed it recently, but not often.
<br>
<br></blockquote><div>Specific demands on UB or not is not daily used. But =
integer itself is.<br><br>In pseudo code:<br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> _Signed</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
_OverflowStrategy _O</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">, </span></code>size_t _Size</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> _Rep </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> _Two_s_complement</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">using</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
__Integer </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> __buil=
tin_int_type</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_</span=
><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">Signed</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"></span></code><span style=3D"color: #008;" class=3D"styled-by-prett=
ify"></span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettypr=
int"><span style=3D"color: #000;" class=3D"styled-by-prettify">_O</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">, _Size</span></code=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><code class=3D"prettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">_Rep</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"></span></code>);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> __Integer</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;true, _Undefined, _Target_int_size&gt;;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify"><code class=3D"prettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> long =3D __Integer&lt=
;</span></code></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">true, _Undefined</span></code>, _Target_long_siz=
e&gt;;<br></span></code>using</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> unsigned =3D __Integer&lt;false, _Never_Overflow_and_Wr=
apped, _Target_unsigned_size&gt;;<br></span></div></code></div><br>Only sig=
nedness can be specified directly be user. (The exact sized integer is opti=
onally provided by the standard library.) All others are not specified by t=
he user, but the policies do exist for every implementation (though some of=
 them might have been <a href=3D"https://en.wikipedia.org/wiki/Partial_eval=
uation">partial evaluated</a>, i.e. fixed at build time of the toolchain). =
In this sense you <i>are </i>daily using them, even if you don&#39;t care t=
he concrete choice mostly.<br><br>I&#39;ll be appreciative if standard libr=
ary can provide such interface with possible to specify the strategy on uns=
igned integers (so I have opportunity to get more optimized code), even if =
other combinations are conditionally-supported. At least the interface can =
be clearer to reflect my intent without verbose comments each time I define=
d an alias.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>And finally, it does not need to be in the core language, as I explained a=
bove.
<br>
<br></blockquote><div>This need to be a core change if portability is neede=
d and standard library does not provide such interface.<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;">&gt; These features are not ra=
ndomly picked. The current design of &quot;signed
<br>&gt; integer overflow is UB but unsigned integer never overflow&quot; s=
till sounds a
<br>&gt; WTF to many C and C++ users. And I&#39;ve see there are people who=
 insists
<br>&gt; signed integers over unsigned integers in general using &quot;sign=
ed integer is
<br>&gt; more friendly to be optimized because overflow is UB&quot; as an e=
xcuse. So why
<br>&gt; unsigned integers deserve to be worse? This makes me to realize th=
e lack of
<br>&gt; these orthogonality is a defect. It is inherited from C, but perha=
ps C++
<br>&gt; can solve it more graceful.
<br>
<br>With classes.
<br>
<br></blockquote><div>With templates.<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6032_1787737823.1449566945520--
------=_Part_6031_1369691005.1449566945514--

.

------=_Part_6409_1864454844.1449583588599
Content-Type: multipart/alternative;
 boundary="----=_Part_6410_986730718.1449583588599"

------=_Part_6410_986730718.1449583588599
Content-Type: text/plain; charset=UTF-8

On Monday, December 7, 2015 at 6:42:52 PM UTC-5, Edward Catmur wrote:
>
>
> On 7 Dec 2015 19:58, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
> >
> > On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wrote:
> >>
> >> <snip>
> >
> >
> > Then I guess we're going to have to agree to disagree then.
> >
> > I don't buy that the fact that something takes more words to describe
> inherently makes it meaningfully more complex. I don't accept your idea
> that changing the language to better fit users expectations is is somehow
> hiding something from them.
> >
> > I don't even understand what "C++ code is being breaking when the rules
> are changed, not the programs" is supposed to mean.
> >
> > I don't accept your assertion that changing code to match user's
> expectations is being unfriendly to experienced users.
>
> It is when you're violating the expectations of experienced users. Oh
> sure, performance is not an observable attribute of the abstract machine.
> But it is a major selling point of C++, and by preventing the compiler
> performing CSE on loads and dependent subexpressions of the same expression
> where there syntactically intervenes a possible store, you're forcing
> experienced users to either do away with separate compilation and type
> erasure, or go back to performing CSE by hand like in the dark ages.
>

First... what's wrong with "performing CSE by hand?" It makes it much more
clear what's going on. It also encourages you to stop writing giant
expressions in your function calls. That sounds like a win in my book.

Second and more importantly, we have seen exactly one case where CSE would
be forbidden under these rules that it would have been both allowed and
*valid* before. Namely, where the common sub-expression involving some
non-const non-local, with an intervening function call which the compiler
*cannot* prove did not change that non-local.

How common is that case?

If you believe that CSE denial under these rules would *significantly*
reduce performance across C++ applications, then it would surely not be a
burdensome task to prove it. If you're right, then in a codebase of
significant size, there must be dozens of places where CSE was validly
employed under the old rules, yet it could not be employed under these.

Show us. Make a case with genuine evidence. In a project the size of Qt,
for example, how many cases are there where CSE could be employed now but
not under the new rules?

It's easy to say that performance will be impacted. It's a lot harder to
actually *prove* it.

People have developed their intuition of optimizer friendly code over
> years, in some cases decades, and you want to throw that all away just for
> the sake of marginally reducing beginner confusion?
>

Have they? I certainly don't base my optimizations on CSE, nor do I write
code based on assuming CSE will happen. Indeed, I personally try to *avoid*
lots of sub-expressions. Part of that is for basic readability, but part of
it is *precisely because* it is undefined. By avoiding sub-expressions, I
avoid the undefined behavior associated with them.

Obviously, I'm just an anecdote. But do you have some proof that this is a
common tool among experienced programmers? What C++ books talk encourage
users to build gargantuan expressions, with the understanding that CSE will
save you from yourself? What evidence do you have that your position is the
correct one?

Furthermore, you ignore the benefits of allowing C++ programmers, beginners
or experienced, to actually rely on the evaluation order of subexpressions.

Also, dismissing this feature as merely "reducing beginner confusion" is
rather silly. What we're reducing is *errors and broken code*. That
beginners are more likely to write such bugs is not really the point; the
fact that it gets written at all is the problem.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, December 7, 2015 at 6:42:52 PM UTC-5, Edward Catmur wrote:<block=
quote 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 7 Dec 2015 19:58, &quot;Nicol Bolas&quot; &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"VGc5n36XCgAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this=
..href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote=
:<br>
&gt;<br>
&gt; On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wrote:<br=
>
&gt;&gt;<br>
&gt;&gt; &lt;snip&gt;<br>
&gt;<br>
&gt;<br>
&gt; Then I guess we&#39;re going to have to agree to disagree then.<br>
&gt;<br>
&gt; I don&#39;t buy that the fact that something takes more words to descr=
ibe inherently makes it meaningfully more complex. I don&#39;t accept your =
idea that changing the language to better fit users expectations is is some=
how hiding something from them.<br>
&gt;<br>
&gt; I don&#39;t even understand what &quot;C++ code is being breaking when=
 the rules are changed, not the programs&quot; is supposed to mean.<br>
&gt;<br>
&gt; I don&#39;t accept your assertion that changing code to match user&#39=
;s expectations is being unfriendly to experienced users.</p>
<p dir=3D"ltr">It is when you&#39;re violating the expectations of experien=
ced users. Oh sure, performance is not an observable attribute of the abstr=
act machine. But it is a major selling point of C++, and by preventing the =
compiler performing CSE on loads and dependent subexpressions of the same e=
xpression where there syntactically intervenes a possible store, you&#39;re=
 forcing experienced users to either do away with separate compilation and =
type erasure, or go back to performing CSE by hand like in the dark ages.</=
p></blockquote><div><br>First... what&#39;s wrong with &quot;performing CSE=
 by hand?&quot; It makes it much more clear what&#39;s going on. It also en=
courages you to stop writing giant expressions in your function calls. That=
 sounds like a win in my book.<br><br>Second and more importantly, we have =
seen exactly one case where CSE would be forbidden under these rules that i=
t would have been both allowed and <i>valid</i> before. Namely, where the c=
ommon sub-expression involving some non-const non-local, with an intervenin=
g function call which the compiler <i>cannot</i> prove did not change that =
non-local.<br><br>How common is that case?<br><br>If you believe that CSE d=
enial under these rules would <i>significantly</i> reduce performance acros=
s C++ applications, then it would surely not be a burdensome task to prove =
it. If you&#39;re right, then in a codebase of significant size, there must=
 be dozens of places where CSE was validly employed under the old rules, ye=
t it could not be employed under these.<br><br>Show us. Make a case with ge=
nuine evidence. In a project the size of Qt, for example, how many cases ar=
e there where CSE could be employed now but not under the new rules?<br><br=
>It&#39;s easy to say that performance will be impacted. It&#39;s a lot har=
der to actually <i>prove</i> it.<br><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;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">People have developed their intuition of optimizer friendly =
code over years, in some cases decades, and you want to throw that all away=
 just for the sake of marginally reducing beginner confusion? <br></p></blo=
ckquote><div><br>Have they? I certainly don&#39;t base my optimizations on =
CSE, nor do I write code based on assuming CSE will happen. Indeed, I perso=
nally try to <i>avoid</i> lots of sub-expressions. Part of that is for basi=
c readability, but part of it is <i>precisely because</i> it is undefined. =
By avoiding sub-expressions, I avoid the undefined behavior associated with=
 them.<br><br>Obviously, I&#39;m just an anecdote. But do you have some pro=
of that this is a common tool among experienced programmers? What C++ books=
 talk encourage users to build gargantuan expressions, with the understandi=
ng that CSE will save you from yourself? What evidence do you have that you=
r position is the correct one?<br><br>Furthermore, you ignore the benefits =
of allowing C++ programmers, beginners or experienced, to actually rely on =
the evaluation order of subexpressions.<br><br>Also, dismissing this featur=
e as merely &quot;reducing beginner confusion&quot; is rather silly. What w=
e&#39;re reducing is <i>errors and broken code</i>. That beginners are more=
 likely to write such bugs is not really the point; the fact that it gets w=
ritten at all is the problem.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6410_986730718.1449583588599--
------=_Part_6409_1864454844.1449583588599--

.

------=_Part_81_1666406518.1449583881500
Content-Type: multipart/alternative;
 boundary="----=_Part_82_1485181351.1449583881501"

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

On Monday, December 7, 2015 at 10:21:10 PM UTC-5, FrankHB1989 wrote:
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8A=E5=8D=882:13:44=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>
>> There is no good reason for not doing the same in C++, but as I have see=
n=20
>> (also for decades), there are plenty of bad ones.
>>
>> There is at least one good reason: to keep newbies who don't bother to=
=20
> learn some basic knowledge to do work serious away.=20
>

"And with that sentence, you just lost the right to even talk to me."

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Monday, December 7, 2015 at 10:21:10 PM UTC-5, FrankHB1=
989 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 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=
=E4=B8=8A=E5=8D=882:13:44=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<br=
><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">There =
is no good reason for not doing the same in C++, but as I have seen (also f=
or decades), there are plenty of bad ones.</div><div><br></div></blockquote=
><div>There is at least one good reason: to keep newbies who don&#39;t both=
er to learn some basic knowledge to do work serious away. <br></div></div><=
/blockquote><div><br>&quot;And with that sentence, you just lost the right =
to even talk to me.&quot;<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_82_1485181351.1449583881501--
------=_Part_81_1666406518.1449583881500--

.

On Tuesday 08 December 2015 01:29:05 FrankHB1989 wrote:
> However, we have some useful features with overhead depending on
> implementation. For example, exception handling nowadays still not always
> meets the zero overhead principle. There is trade off.

Agreed.

> And allowing UB on unsigned integer is loosing the restriction. At least
> this feature will introduce no more overhead. There is even no more work
> required to do for compiler backend to support it, because the current
> unsigned integers are also conforming.

Unsigned integer operations do not UB. Just be careful with unsigned integers
of rank less than that of int, which means they get promoted to int before the
operation, so the operation was not on unsigned integers, but on a signed one.

> > It
> > can be a class, implemented entirely in library code. In fact, with the
> > GCC
> > and Clang __builtin_{add,sub,mul}_overflow intrinsics, it should be
> > possible to
> > do just that.
> >
> The "portable" way is in the sense of standard, e.g. UB is "not portable".
>
> Even "__builtin_" can be hopefully portable between GCC and Clang, using of
> identifier beginning with double underscore is definitely not portable C++.
> Though in practice they can  be wrapped as macros.

I never meant for the users to have to type "__builtin". My point is that this
functionality can be provided as a class in the Standard Library, not as
primitive type. The GCC and Clang implementations of this would use
__builtin_{add,sub,mul}_overflow, while the Visual C++ implementation would use
_addcarry_uXX. _subborrow_uXX, _umul64/128. Other implementations may have
assembly code, while some others may just do integer math to calculate whether
an overflow would happen before it happens.

> Specific demands on UB or not is not daily used. But integer itself is.

Integers are, but daily needs are satisfied already. It's the uncommon needs
that need to be satisfied, which is why I am saying this does not need to be a
primitive type.

> I'll be appreciative if standard library can provide such interface with
> possible to specify the strategy on unsigned integers (so I have
> opportunity to get more optimized code), even if other combinations are
> conditionally-supported. At least the interface can be clearer to reflect
> my intent without verbose comments each time I defined an alias.

Write a paper with the possible overflow modes. A sample implementation would
be a good idea too.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_3202_1316271199.1449624924916
Content-Type: multipart/alternative;
 boundary="----=_Part_3203_793063406.1449624924916"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8810:11:21=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Monday, December 7, 2015 at 10:21:10 PM UTC-5, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C =
UTC+8=E4=B8=8A=E5=8D=882:13:44=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>>> There is no good reason for not doing the same in C++, but as I have=20
>>> seen (also for decades), there are plenty of bad ones.
>>>
>>> There is at least one good reason: to keep newbies who don't bother to=
=20
>> learn some basic knowledge to do work serious away.=20
>>
>
> "And with that sentence, you just lost the right to even talk to me."
>

I'm not sure what you are talking about. Are you arguing that you are just=
=20
the newbie who don't bother it? Anyway, they'd better not care about this=
=20
topic; better go for homework before trying to change an industrial=20
standard.

Whether I have rights or not here is nonsense. You are still disabled to=20
deny the 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=8C UTC+8=E4=B8=8B=E5=8D=8810:11:21=EF=BC=8CNicol Bolas=E5=86=99=E9=81=
=93=EF=BC=9A<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">O=
n Monday, December 7, 2015 at 10:21:10 PM UTC-5, 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">=E5=9C=A8 2015=E5=B9=B412=
=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=882:13:=
44=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<br><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">There is no good reason for n=
ot doing the same in C++, but as I have seen (also for decades), there are =
plenty of bad ones.</div><div><br></div></blockquote><div>There is at least=
 one good reason: to keep newbies who don&#39;t bother to learn some basic =
knowledge to do work serious away. <br></div></div></blockquote><div><br>&q=
uot;And with that sentence, you just lost the right to even talk to me.&quo=
t;<br></div></div></blockquote><div><br>I&#39;m not sure what you are talki=
ng about. Are you arguing that you are just the newbie who don&#39;t bother=
 it? Anyway, they&#39;d better not care about this topic; better go for hom=
ework before trying to change an industrial standard.<br><br>Whether I have=
 rights or not here is nonsense. You are still disabled to deny the fact.<b=
r><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3203_793063406.1449624924916--
------=_Part_3202_1316271199.1449624924916--

.

------=_Part_2752_2085643455.1449627381390
Content-Type: multipart/alternative;
 boundary="----=_Part_2753_1095675599.1449627381390"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8811:50:35=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Tuesday 08 December 2015 01:29:05 FrankHB1989 wrote:=20
> > However, we have some useful features with overhead depending on=20
> > implementation. For example, exception handling nowadays still not=20
> always=20
> > meets the zero overhead principle. There is trade off.=20
>
> Agreed.=20
>
> > And allowing UB on unsigned integer is loosing the restriction. At leas=
t=20
> > this feature will introduce no more overhead. There is even no more wor=
k=20
> > required to do for compiler backend to support it, because the current=
=20
> > unsigned integers are also conforming.=20
>
> Unsigned integer operations do not UB. Just be careful with unsigned=20
> integers=20
> of rank less than that of int, which means they get promoted to int befor=
e=20
> the=20
> operation, so the operation was not on unsigned integers, but on a signed=
=20
> one.=20
>
> Yes. Unsigned integers are UB-free in this sense.

But there are people who want to *allow UB* on integers when they can=20
guarantee no overflow would actually occur by their careful use, to allow=
=20
the code being optimized more aggressively.

There do exist such cases.

And I think it is strange to make difference deliberately between signed=20
and unsigned integers. Are unsigned integers with UB hard to implement? I=
=20
don't think so. Why all unsigned integers should behave differently to=20
signed integers? I don't find it reasonable.

Unsigned integer with modular arithmetic are still useful. So is it better=
=20
having both of them?
=20

> > > It=20
> > > can be a class, implemented entirely in library code. In fact, with=
=20
> the=20
> > > GCC=20
> > > and Clang __builtin_{add,sub,mul}_overflow intrinsics, it should be=
=20
> > > possible to=20
> > > do just that.=20
> > >=20
> > The "portable" way is in the sense of standard, e.g. UB is "not=20
> portable".=20
> >=20
> > Even "__builtin_" can be hopefully portable between GCC and Clang, usin=
g=20
> of=20
> > identifier beginning with double underscore is definitely not portable=
=20
> C++.=20
> > Though in practice they can  be wrapped as macros.=20
>
> I never meant for the users to have to type "__builtin". My point is that=
=20
> this=20
> functionality can be provided as a class in the Standard Library, not as=
=20
> primitive type. The GCC and Clang implementations of this would use=20
> __builtin_{add,sub,mul}_overflow, while the Visual C++ implementation=20
> would use=20
> _addcarry_uXX. _subborrow_uXX, _umul64/128. Other implementations may hav=
e=20
> assembly code, while some others may just do integer math to calculate=20
> whether=20
> an overflow would happen before it happens.=20
>
> Got it.=20

> > Specific demands on UB or not is not daily used. But integer itself is.=
=20
>
> Integers are, but daily needs are satisfied already.

It depends. I would not care it too much for internal use as automatic=20
objects. They are just "satisfied" here.

For other uses, it may be not. In fact, guaranteed no overflow on unsigned=
=20
integer became an excuse to not use unsigned integers in interface, even=20
if  the range of  the integer is definitely unsigned. It occurs in standard=
=20
library, e.g. return type of std::shared_ptr::use_count and=20
std::uncaught_exceptions.

This trend is bad. It does not reflect to the original real intend *by=20
design*. But this excuse is technically correct, until fix the whole by=20
introducing unsigned integers allowing UB like signed integers.

It's the uncommon needs=20
> that need to be satisfied, which is why I am saying this does not need to=
=20
> be a=20
> primitive type.=20
>
> I don't agree it can be a sufficient reason to determine what is=20
"primitive".

Theoretically all other types can be designed in this way, with only a few=
=20
exceptions which need special core rules to distinguish:

   - void types
   - boolean type which occurs in wording of core language construct (like=
=20
   if statements)
   - return type for program entry (now it is mandated to be int in C++;=20
   however, this can be loosed as freestanding implementation of C, which d=
oes=20
   not require 'main' at all)
   - placeholder type built in other core language rules, like type to=20
   indicate overloading postfix operator++ (now it is int)

Even These special types can be provided by the library instead directly=20
hard-coded in core rules (like std::nullptr_t), but it may be too subtle to=
=20
use and will provide no more benefit than current status.


Most primitive types are not special. They just *have been* primitive for=
=20
some reasons (e.g. copied from C), but not *have to*. Core language are not=
=20
required to depending on them. Note that character types like wchar_t can=
=20
have be non-primitive in C++, like currently C do. They are primitive due=
=20
to the design choice of C++, to provide more type safety and better literal=
=20
support. Other integers are still not so specific.

=20

> > I'll be appreciative if standard library can provide such interface wit=
h=20
> > possible to specify the strategy on unsigned integers (so I have=20
> > opportunity to get more optimized code), even if other combinations are=
=20
> > conditionally-supported. At least the interface can be clearer to=20
> reflect=20
> > my intent without verbose comments each time I defined an alias.=20
>
> Write a paper with the possible overflow modes. A sample implementation=
=20
> would=20
> be a good idea too.=20
>
> Probably in future. Currently I have little clue to figure out the proper=
=20
style of interface. To illustrate the benefit, some implementation-specific=
=20
work are also needed.=20

> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=8C UTC+8=E4=B8=8B=E5=8D=8811:50:35=EF=BC=8CThiago Macieira=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;">On Tuesday 08 D=
ecember 2015 01:29:05 FrankHB1989 wrote:
<br>&gt; However, we have some useful features with overhead depending on
<br>&gt; implementation. For example, exception handling nowadays still not=
 always
<br>&gt; meets the zero overhead principle. There is trade off.
<br>
<br>Agreed.
<br>
<br>&gt; And allowing UB on unsigned integer is loosing the restriction. At=
 least
<br>&gt; this feature will introduce no more overhead. There is even no mor=
e work
<br>&gt; required to do for compiler backend to support it, because the cur=
rent
<br>&gt; unsigned integers are also conforming.
<br>
<br>Unsigned integer operations do not UB. Just be careful with unsigned in=
tegers=20
<br>of rank less than that of int, which means they get promoted to int bef=
ore the=20
<br>operation, so the operation was not on unsigned integers, but on a sign=
ed one.
<br>
<br></blockquote><div>Yes. Unsigned integers are UB-free in this sense.<br>=
<br>But there are people who want to <i>allow UB</i> on integers when they =
can guarantee no overflow would actually occur by their careful use, to all=
ow the code being optimized more aggressively.<br><br>There do exist such c=
ases.<br><br>And I think it is strange to make difference deliberately betw=
een signed and unsigned integers. Are unsigned integers with UB hard to imp=
lement? I don&#39;t think so. Why all unsigned integers should behave diffe=
rently to signed integers? I don&#39;t find it reasonable.<br><br>Unsigned =
integer with modular arithmetic are still useful. So is it better having bo=
th of them?<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>&gt; &gt; It
<br>&gt; &gt; can be a class, implemented entirely in library code. In fact=
, with the
<br>&gt; &gt; GCC
<br>&gt; &gt; and Clang __builtin_{add,sub,mul}_<wbr>overflow intrinsics, i=
t should be
<br>&gt; &gt; possible to
<br>&gt; &gt; do just that.
<br>&gt; &gt;=20
<br>&gt; The &quot;portable&quot; way is in the sense of standard, e.g. UB =
is &quot;not portable&quot;.
<br>&gt;=20
<br>&gt; Even &quot;__builtin_&quot; can be hopefully portable between GCC =
and Clang, using of
<br>&gt; identifier beginning with double underscore is definitely not port=
able C++.
<br>&gt; Though in practice they can =C2=A0be wrapped as macros.
<br>
<br>I never meant for the users to have to type &quot;__builtin&quot;. My p=
oint is that this=20
<br>functionality can be provided as a class in the Standard Library, not a=
s=20
<br>primitive type. The GCC and Clang implementations of this would use=20
<br>__builtin_{add,sub,mul}_<wbr>overflow, while the Visual C++ implementat=
ion would use=20
<br>_addcarry_uXX. _subborrow_uXX, _umul64/128. Other implementations may h=
ave=20
<br>assembly code, while some others may just do integer math to calculate =
whether=20
<br>an overflow would happen before it happens.
<br>
<br></blockquote><div>Got it. <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;">&gt; Specific demands on UB or not is not daily used. But integer=
 itself is.
<br>
<br>Integers are, but daily needs are satisfied already.</blockquote><div>I=
t depends. I would not care it too much for internal use as automatic objec=
ts. They are just &quot;satisfied&quot; here.<br><br>For other uses, it may=
 be not. In fact, guaranteed no overflow on unsigned integer became an excu=
se to not use unsigned integers in interface, even if=C2=A0 the range of=C2=
=A0 the integer is definitely unsigned. It occurs in standard library, e.g.=
 return type of std::shared_ptr::use_count and std::uncaught_exceptions.<br=
><br>This trend is bad. It does not reflect to the original real intend <i>=
by design</i>. But this excuse is technically correct, until fix the whole =
by introducing unsigned integers allowing UB like signed integers.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">It&#39;s the uncommon nee=
ds=20
<br>that need to be satisfied, which is why I am saying this does not need =
to be a=20
<br>primitive type.
<br>
<br></blockquote><div>I don&#39;t agree it can be a sufficient reason to de=
termine what is &quot;primitive&quot;.<br><br>Theoretically all other types=
 can be designed in this way, with only a few exceptions which need special=
 core rules to distinguish:<br><ul><li>void types</li><li>boolean type whic=
h occurs in wording of core language construct (like if statements)<br></li=
><li>return type for program entry (now it is mandated to be int in C++; ho=
wever, this can be loosed as freestanding implementation of C, which does n=
ot require &#39;main&#39; at all)</li><li>placeholder type built in other c=
ore language rules, like type to indicate overloading postfix operator++ (n=
ow it is int)</li></ul><p>Even These special types can be provided by the l=
ibrary instead directly hard-coded in core rules (like std::nullptr_t), but=
 it may be too subtle to use and will provide no more benefit than current =
status.<br></p><p><br></p><p>Most primitive types are not special. They jus=
t <i>have been</i> primitive for some reasons (e.g. copied from C), but not=
 <i>have to</i>. Core language are not required to depending on them. Note =
that character types like wchar_t can have be non-primitive in C++, like cu=
rrently C do. They are primitive due to the design choice of C++, to provid=
e more type safety and better literal support. Other integers are still not=
 so specific.<br></p><p>=C2=A0<br></p></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">&gt; I&#39;ll be appreciative if standard library can provide=
 such interface with
<br>&gt; possible to specify the strategy on unsigned integers (so I have
<br>&gt; opportunity to get more optimized code), even if other combination=
s are
<br>&gt; conditionally-supported. At least the interface can be clearer to =
reflect
<br>&gt; my intent without verbose comments each time I defined an alias.
<br>
<br>Write a paper with the possible overflow modes. A sample implementation=
 would=20
<br>be a good idea too.
<br>
<br></blockquote><div>Probably in future. Currently I have little clue to f=
igure out the proper style of interface. To illustrate the benefit, some im=
plementation-specific work are also needed. <br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46snt=
z\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;">maciei=
ra.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1Dowztw=
AHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google=
..com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo=
5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2753_1095675599.1449627381390--
------=_Part_2752_2085643455.1449627381390--

.

On Tuesday 08 December 2015 18:16:21 FrankHB1989 wrote:
> > Yes. Unsigned integers are UB-free in this sense.
>
> But there are people who want to *allow UB* on integers when they can
> guarantee no overflow would actually occur by their careful use, to allow
> the code being optimized more aggressively.

That would require compiler help. But since we're talking about aggressive
optimisation, we are talking about compiler specifics.

From the standard's point of view, nothing needs to be done. An implementation
that overflows by modulo-2 wrapping is a perfectly valid implementation of UB.

> There do exist such cases.

I don't doubt it.

> And I think it is strange to make difference deliberately between signed
> and unsigned integers. Are unsigned integers with UB hard to implement? I
> don't think so. Why all unsigned integers should behave differently to
> signed integers? I don't find it reasonable.

Implementing UB is not hard. It means removing code :-)

As for reasonable, it's in the eye of the beholder. I can tell you why it is
the way it is, which has a logic of its own, and therefore is reasonable under
those parameters.

The point was that unsigned integers are defined to be represented in regular
binary with modulo 2 overflow. There aren't any other types of unsigned
numbers. So the language simply says what the machine does anyway.

On the other hand, signed integers can be represented in one of three forms:
 - sign + magnitude
 - one's complement
 - two's complement

Since the language must work on all types of machines, it was decided not to
penalise any one of them. So the behaviours that depend on how signed integers
are represented are left undefined.

It's true that sign + magnitude and one's complement machines are rare these
days. They may have been more common in the 70s, when C was invented, and in
the 80s, when C was standardised. (Note: integers; IEEE 754 floating point are
sign + magnitude)

> For other uses, it may be not. In fact, guaranteed no overflow on unsigned
> integer became an excuse to not use unsigned integers in interface, even
> if  the range of  the integer is definitely unsigned. It occurs in standard
> library, e.g. return type of std::shared_ptr::use_count and
> std::uncaught_exceptions.

Agreed that it would remove one more reason, but not all. There are other
reasons to use signed integers, especially int, even if the range is unsigned
or even positive. Ease of use counts a lot, which includes the lack of
warnings of signed/unsigned mismatches in comparisons, assignment, etc.

> This trend is bad. It does not reflect to the original real intend *by
> design*. But this excuse is technically correct, until fix the whole by
> introducing unsigned integers allowing UB like signed integers.

It still follows the original intent, as outlined above.

> Theoretically all other types can be designed in this way, with only a few
> exceptions which need special core rules to distinguish:
>
>    - void types
>    - boolean type which occurs in wording of core language construct (like
>    if statements)
>    - return type for program entry (now it is mandated to be int in C++;
>    however, this can be loosed as freestanding implementation of C, which
> does not require 'main' at all)
>    - placeholder type built in other core language rules, like type to
>    indicate overloading postfix operator++ (now it is int)

In a blue sky scenario, yes. But we're not in that scenario. We are 45 years
into legacy of C, where the primitive types already exist. What's more,
there's a much higher barrier of entry to modify the core language, while
modifying the Standard Library is much more achievable.

That's why the committee's recommendation is that what can be reasonably done
in the library should be done in the library. "Reasonably" indeed implies a
subjective qualification, so arguments should be presented why or why not do
something in some way.

So far, I have seen little reason why primitive, built-in types would be
required. Library is enough.

[Which isn't to say compiler writers won't create something primitive. See the
std::atomic implementation based on the C11 _Atomic. But that's implementation
detail.]

> Even These special types can be provided by the library instead directly
> hard-coded in core rules (like std::nullptr_t), but it may be too subtle to
> use and will provide no more benefit than current status.

If you have no good reason to use them, why should you use them?

> Most primitive types are not special. They just *have been* primitive for
> some reasons (e.g. copied from C), but not *have to*. Core language are not
> required to depending on them. Note that character types like wchar_t can
> have be non-primitive in C++, like currently C do. They are primitive due
> to the design choice of C++, to provide more type safety and better literal
> support. Other integers are still not so specific.

Correct.

> > Write a paper with the possible overflow modes. A sample implementation
> > would
> > be a good idea too.
> >
> Probably in future. Currently I have little clue to figure out the proper
> style of interface. To illustrate the benefit, some implementation-specific
> work are also needed.

Of course.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bd760c278a2fc0526781176
Content-Type: text/plain; charset=UTF-8

On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, December 7, 2015 at 6:42:52 PM UTC-5, Edward Catmur wrote:
>>
>> On 7 Dec 2015 19:58, "Nicol Bolas" <jmck...@gmail.com> wrote:
>> >
>> > On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wrote:
>> >>
>> >> <snip>
>> >
>> >
>> > Then I guess we're going to have to agree to disagree then.
>> >
>> > I don't buy that the fact that something takes more words to describe
>> inherently makes it meaningfully more complex. I don't accept your idea
>> that changing the language to better fit users expectations is is somehow
>> hiding something from them.
>> >
>> > I don't even understand what "C++ code is being breaking when the rules
>> are changed, not the programs" is supposed to mean.
>> >
>> > I don't accept your assertion that changing code to match user's
>> expectations is being unfriendly to experienced users.
>>
>> It is when you're violating the expectations of experienced users. Oh
>> sure, performance is not an observable attribute of the abstract machine.
>> But it is a major selling point of C++, and by preventing the compiler
>> performing CSE on loads and dependent subexpressions of the same expression
>> where there syntactically intervenes a possible store, you're forcing
>> experienced users to either do away with separate compilation and type
>> erasure, or go back to performing CSE by hand like in the dark ages.
>>
>
> First... what's wrong with "performing CSE by hand?" It makes it much more
> clear what's going on. It also encourages you to stop writing giant
> expressions in your function calls. That sounds like a win in my book.
>

Not if all you're doing is copying reference parameters and member
variables into locals - that's just renaming. Similarly, an expression can
be highly succinct but contain calls to inline functions and member
functions whose contents could be coalesced.

Second and more importantly, we have seen exactly one case where CSE would
> be forbidden under these rules that it would have been both allowed and
> *valid* before. Namely, where the common sub-expression involving some
> non-const non-local, with an intervening function call which the compiler
> *cannot* prove did not change that non-local.
>

Non-locals are almost always non-const, unless they're actual compile-time
constants; they exist in the imperative subset of C++. For the intervening
function call, even if the compiler can prove the non-local is not changed,
that's not the end of it; the programmer has to be satisfied that the
compiler will always be able to prove it.


> How common is that case?
>
> If you believe that CSE denial under these rules would *significantly*
> reduce performance across C++ applications, then it would surely not be a
> burdensome task to prove it. If you're right, then in a codebase of
> significant size, there must be dozens of places where CSE was validly
> employed under the old rules, yet it could not be employed under these.
>
> Show us. Make a case with genuine evidence. In a project the size of Qt,
> for example, how many cases are there where CSE could be employed now but
> not under the new rules?
>

OK, here's one in Qt, found just by browsing recent commits:
https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243

int n = textLayout()->nextCursorPosition(m_cursor) - m_cursor;
Currently, the loads from m_cursor can be collapsed; in the presence of
fixed evaluation order the LHS subexpression could change the value of
m_cursor so it has to be reloaded.


> It's easy to say that performance will be impacted. It's a lot harder to
> actually *prove* it.
>

Surely at least some of the burden of proof is on those proposing the
change?

> People have developed their intuition of optimizer friendly code over
>> years, in some cases decades, and you want to throw that all away just for
>> the sake of marginally reducing beginner confusion?
>>
>
> Have they? I certainly don't base my optimizations on CSE, nor do I write
> code based on assuming CSE will happen. Indeed, I personally try to
> *avoid* lots of sub-expressions. Part of that is for basic readability,
> but part of it is *precisely because* it is undefined. By avoiding
> sub-expressions, I avoid the undefined behavior associated with them.
>

Are you sure? C++ is sufficiently powerful that a syntactically simple
expression may hide plenty of complexity: implicit conversions, member
variables, reference parameters and captures, and so on. The complexity
behind that power is only supportable because the compiler is permitted to
optimize much of it away.

By the way: UB only occurs with multiple stores; I would absolutely agree
that any expression involving multiple stores probably needs to be
refactored. The specific issue here is multiple loads.

As far as readability goes, the issue cuts both ways; yes, some multi-line
monstrosity may be unreadable, but chopping it up into single-operation
statements can be just as hard to read, not to mention the burden on the
programmer of naming the intermediate values and on the maintainer of
tracking which are actually used in the final result - these are things
that can and should be done by the compiler.


> Obviously, I'm just an anecdote. But do you have some proof that this is a
> common tool among experienced programmers? What C++ books talk encourage
> users to build gargantuan expressions, with the understanding that CSE will
> save you from yourself? What evidence do you have that your position is the
> correct one?
>

I hardly think the above expression (from Qt) is "gargantuan".


> Furthermore, you ignore the benefits of allowing C++ programmers,
> beginners or experienced, to actually rely on the evaluation order of
> subexpressions.
>

That's really not a benefit. If large, complicated expressions are bad, how
much worse are large, complicated expressions with multiple side-effects?


> Also, dismissing this feature as merely "reducing beginner confusion" is
> rather silly. What we're reducing is *errors and broken code*. That
> beginners are more likely to write such bugs is not really the point; the
> fact that it gets written at all is the problem.
>

You're implying a false equivalence between bugs written by beginners in
the course of learning the language, and bugs written by experienced users
in production code. The former impose an economic cost only on the beginner
themselves, possibly also their peers and tutors depending on how easy they
are to spot, which may well be worth it if the end result is a deeper
understanding of a more powerful 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bd760c278a2fc0526781176
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, Dec 8, 2015 at 2:06 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> 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">On Monday, December 7, 2015 at 6:42:52 PM UT=
C-5, Edward Catmur 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);=
border-left-style:solid;padding-left:1ex"><p dir=3D"ltr">On 7 Dec 2015 19:5=
8, &quot;Nicol Bolas&quot; &lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt=
; wrote:<br>
&gt;<br>
&gt; On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wrote:<br=
>
&gt;&gt;<br>
&gt;&gt; &lt;snip&gt;<br>
&gt;<br>
&gt;<br>
&gt; Then I guess we&#39;re going to have to agree to disagree then.<br>
&gt;<br>
&gt; I don&#39;t buy that the fact that something takes more words to descr=
ibe inherently makes it meaningfully more complex. I don&#39;t accept your =
idea that changing the language to better fit users expectations is is some=
how hiding something from them.<br>
&gt;<br>
&gt; I don&#39;t even understand what &quot;C++ code is being breaking when=
 the rules are changed, not the programs&quot; is supposed to mean.<br>
&gt;<br>
&gt; I don&#39;t accept your assertion that changing code to match user&#39=
;s expectations is being unfriendly to experienced users.</p>
<p dir=3D"ltr">It is when you&#39;re violating the expectations of experien=
ced users. Oh sure, performance is not an observable attribute of the abstr=
act machine. But it is a major selling point of C++, and by preventing the =
compiler performing CSE on loads and dependent subexpressions of the same e=
xpression where there syntactically intervenes a possible store, you&#39;re=
 forcing experienced users to either do away with separate compilation and =
type erasure, or go back to performing CSE by hand like in the dark ages.</=
p></blockquote><div><br>First... what&#39;s wrong with &quot;performing CSE=
 by hand?&quot; It makes it much more clear what&#39;s going on. It also en=
courages you to stop writing giant expressions in your function calls. That=
 sounds like a win in my book.<br></div></blockquote><div><br></div><div>No=
t if all you&#39;re doing is copying reference parameters and member variab=
les into locals - that&#39;s just renaming. Similarly, an expression can be=
 highly succinct but contain calls to inline functions and member functions=
 whose contents could be coalesced.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div>Second and more importantly, we have seen exactly one case where CSE w=
ould be forbidden under these rules that it would have been both allowed an=
d <i>valid</i> before. Namely, where the common sub-expression involving so=
me non-const non-local, with an intervening function call which the compile=
r <i>cannot</i> prove did not change that non-local.<br></div></blockquote>=
<div><br></div><div>Non-locals are almost always non-const, unless they&#39=
;re actual compile-time constants; they exist in the imperative subset of C=
++. For the intervening function call, even if the compiler can prove the n=
on-local is not changed, that&#39;s not the end of it; the programmer has t=
o be satisfied that the compiler will always be able to prove it.</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>How common is that case?<br><br>If you b=
elieve that CSE denial under these rules would <i>significantly</i> reduce =
performance across C++ applications, then it would surely not be a burdenso=
me task to prove it. If you&#39;re right, then in a codebase of significant=
 size, there must be dozens of places where CSE was validly employed under =
the old rules, yet it could not be employed under these.<br><br>Show us. Ma=
ke a case with genuine evidence. In a project the size of Qt, for example, =
how many cases are there where CSE could be employed now but not under the =
new rules?<br></div></blockquote><div><br></div><div>OK, here&#39;s one in =
Qt, found just by browsing recent commits:=C2=A0<a href=3D"https://github.c=
om/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad42150b0bc03/src/widge=
ts/widgets/qwidgetlinecontrol.cpp#L243">https://github.com/qtproject/qtbase=
/blob/f37ea6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetl=
inecontrol.cpp#L243</a></div><div><br></div><div><table class=3D"" style=3D=
"border-collapse:collapse;border-spacing:0px;color:rgb(51,51,51);font-famil=
y:Helvetica,arial,nimbussansl,liberationsans,freesans,clean,sans-serif,&#39=
;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;=
font-size:13px;line-height:18.2000007629395px"><tbody><tr></tr><tr><td id=
=3D"LC243" class=3D"" style=3D"padding:0px 10px;vertical-align:top;font-fam=
ily:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:12=
px;white-space:pre;overflow:visible;word-wrap:normal;background-color:rgb(2=
48,238,199)">        <span class=3D"" style=3D"color:rgb(167,29,93)">int</s=
pan> n =3D <span class=3D"" style=3D"color:rgb(0,134,179)">textLayout</span=
>()-&gt;<span class=3D"" style=3D"color:rgb(0,134,179)">nextCursorPosition<=
/span>(m_cursor) - m_cursor;</td></tr><tr><td id=3D"L244" class=3D"" style=
=3D"padding:0px 10px;width:50px;min-width:50px;white-space:nowrap;font-fami=
ly:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:12p=
x;line-height:18px;color:rgba(0,0,0,0.298039);vertical-align:top;text-align=
:right;border-style:solid;border-color:rgb(238,238,238);border-width:0px 1p=
x 0px 0px"></td></tr></tbody></table><br></div><div>Currently, the loads fr=
om m_cursor can be collapsed; in the presence of fixed evaluation order the=
 LHS subexpression could change the value of m_cursor so it has to be reloa=
ded.</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>It&#39;s easy to say that =
performance will be impacted. It&#39;s a lot harder to actually <i>prove</i=
> it.<br></div></blockquote><div><br></div><div>Surely at least some of the=
 burden of proof is on those proposing the change?<br></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></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"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">People have developed their intuition of optimizer friendly =
code over years, in some cases decades, and you want to throw that all away=
 just for the sake of marginally reducing beginner confusion? <br></p></blo=
ckquote><div><br>Have they? I certainly don&#39;t base my optimizations on =
CSE, nor do I write code based on assuming CSE will happen. Indeed, I perso=
nally try to <i>avoid</i> lots of sub-expressions. Part of that is for basi=
c readability, but part of it is <i>precisely because</i> it is undefined. =
By avoiding sub-expressions, I avoid the undefined behavior associated with=
 them.<br></div></blockquote><div><br></div><div>Are you sure? C++ is suffi=
ciently powerful that a syntactically simple expression may hide plenty of =
complexity: implicit conversions, member variables, reference parameters an=
d captures, and so on. The complexity behind that power is only supportable=
 because the compiler is permitted to optimize much of it away.</div><div><=
br></div><div>By the way: UB only occurs with multiple stores; I would abso=
lutely agree that any expression involving multiple stores probably needs t=
o be refactored. The specific issue here is multiple loads.</div><div><br><=
/div><div>As far as readability goes, the issue cuts both ways; yes, some m=
ulti-line monstrosity may be unreadable, but chopping it up into single-ope=
ration statements can be just as hard to read, not to mention the burden on=
 the programmer of naming the intermediate values and on the maintainer of =
tracking which are actually used in the final result - these are things tha=
t can and should be done by the compiler.</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>Obviously, I&#39;m just an anecdote. But do you have some proof =
that this is a common tool among experienced programmers? What C++ books ta=
lk encourage users to build gargantuan expressions, with the understanding =
that CSE will save you from yourself? What evidence do you have that your p=
osition is the correct one?<br></div></blockquote><div><br></div><div>I har=
dly think the above expression (from Qt) is &quot;gargantuan&quot;.</div><d=
iv>=C2=A0</div><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>Furthermore, you ignore the benefits o=
f allowing C++ programmers, beginners or experienced, to actually rely on t=
he evaluation order of subexpressions.<br></div></blockquote><div><br></div=
><div>That&#39;s really not a benefit. If large, complicated expressions ar=
e bad, how much worse are large, complicated expressions with multiple side=
-effects?</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,20=
4,204);border-left-style:solid;padding-left:1ex"><div>Also, dismissing this=
 feature as merely &quot;reducing beginner confusion&quot; is rather silly.=
 What we&#39;re reducing is <i>errors and broken code</i>. That beginners a=
re more likely to write such bugs is not really the point; the fact that it=
 gets written at all is the problem.</div></blockquote><div><br></div><div>=
You&#39;re implying a false equivalence between bugs written by beginners i=
n the course of learning the language, and bugs written by experienced user=
s in production code. The former impose an economic cost only on the beginn=
er themselves, possibly also their peers and tutors depending on how easy t=
hey are to spot, which may well be worth it if the end result is a deeper u=
nderstanding of a more powerful language.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bd760c278a2fc0526781176--

.

On 2015-12-09 09:40, 'Edward Catmur' wrote:
> On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:
>> Show us. Make a case with genuine evidence. In a project the size of Qt,
>> for example, how many cases are there where CSE could be employed now but
>> not under the new rules?
>
> OK, here's one in Qt, found just by browsing recent commits:
> https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243
>
> int n = textLayout()->nextCursorPosition(m_cursor) - m_cursor;
> Currently, the loads from m_cursor can be collapsed; in the presence of
> fixed evaluation order the LHS subexpression could change the value of
> m_cursor so it has to be reloaded.

I wonder if this example works...? On the one hand, textLayout() is a
const method, so cannot change m_cursor. On the other, it returns a
mutable object of another type, whose methods may not be inline, and I
doubt the compiler can statically prove that methods called on the other
object can't modify (in this example) m_cursor. (Certainly I could
readily contrive a pathological example that does exactly that in a way
that the compiler can't detect.)

So... ah, yeah. Ick. I *was* ambivalent as to this proposal, until that
example. Now I'm not thrilled with it myself...

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_10324_1882835603.1449695298009
Content-Type: multipart/alternative;
 boundary="----=_Part_10325_266474116.1449695298009"

------=_Part_10325_266474116.1449695298009
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 9, 2015 at 7:37:37 AM UTC-8, Matthew Woehlke wrote:
>
> On 2015-12-09 09:40, 'Edward Catmur' wrote:
> > On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:
> >> Show us. Make a case with genuine evidence. In a project the size of
> Qt,
> >> for example, how many cases are there where CSE could be employed now
> but
> >> not under the new rules?
> >
> > OK, here's one in Qt, found just by browsing recent commits:
> >
> https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243
> >
> > int n = textLayout()->nextCursorPosition(m_cursor) - m_cursor;
> > Currently, the loads from m_cursor can be collapsed; in the presence of
> > fixed evaluation order the LHS subexpression could change the value of
> > m_cursor so it has to be reloaded.
>
> I wonder if this example works...? On the one hand, textLayout() is a
> const method, so cannot change m_cursor. On the other, it returns a
> mutable object of another type, whose methods may not be inline, and I
> doubt the compiler can statically prove that methods called on the other
> object can't modify (in this example) m_cursor. (Certainly I could
> readily contrive a pathological example that does exactly that in a way
> that the compiler can't detect.)
>
> So... ah, yeah. Ick. I *was* ambivalent as to this proposal, until that
> example. Now I'm not thrilled with it myself...
>
>
If the evaluation order were only guaranteed for certain operators, - would
likely not be one of them.

int n = textLayout()->nextCursorPosition(m_cursor) - m_cursor;

In this case, the sequenced-before guarantees would be that the
textLayout() function call occurs before
SomeLayoutType::nextCursorPosition().  The reading of m_cursor, either for
the function parameter or the subtrahend, would be unsequenced relative to
the others.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Wednesday, December 9, 2015 at 7:37:37 AM UTC-8, Matthew Woehlke wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-09 09:40, &#39;Edwar=
d Catmur&#39; wrote:
<br>&gt; On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:
<br>&gt;&gt; Show us. Make a case with genuine evidence. In a project the s=
ize of Qt,
<br>&gt;&gt; for example, how many cases are there where CSE could be emplo=
yed now but
<br>&gt;&gt; not under the new rules?
<br>&gt;=20
<br>&gt; OK, here&#39;s one in Qt, found just by browsing recent commits:
<br>&gt; <a href=3D"https://github.com/qtproject/qtbase/blob/f37ea6c5c61099=
851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243"=
 target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https:/=
/www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fqtproject%2Fqtbase%2Fblo=
b%2Ff37ea6c5c61099851d9df57c8d7ad42150b0bc03%2Fsrc%2Fwidgets%2Fwidgets%2Fqw=
idgetlinecontrol.cpp%23L243\46sa\75D\46sntz\0751\46usg\75AFQjCNFoYl-9DbQgcc=
gNskoL2PH5Oj4Xkg&#39;;return true;" onclick=3D"this.href=3D&#39;https://www=
..google.com/url?q\75https%3A%2F%2Fgithub.com%2Fqtproject%2Fqtbase%2Fblob%2F=
f37ea6c5c61099851d9df57c8d7ad42150b0bc03%2Fsrc%2Fwidgets%2Fwidgets%2Fqwidge=
tlinecontrol.cpp%23L243\46sa\75D\46sntz\0751\46usg\75AFQjCNFoYl-9DbQgccgNsk=
oL2PH5Oj4Xkg&#39;;return true;">https://github.com/qtproject/<wbr>qtbase/bl=
ob/<wbr>f37ea6c5c61099851d9df57c8d7ad4<wbr>2150b0bc03/src/widgets/<wbr>widg=
ets/qwidgetlinecontrol.<wbr>cpp#L243</a>
<br>&gt;=20
<br>&gt; int n =3D textLayout()-&gt;<wbr>nextCursorPosition(m_cursor) - m_c=
ursor;
<br>&gt; Currently, the loads from m_cursor can be collapsed; in the presen=
ce of
<br>&gt; fixed evaluation order the LHS subexpression could change the valu=
e of
<br>&gt; m_cursor so it has to be reloaded.
<br>
<br>I wonder if this example works...? On the one hand, textLayout() is a
<br>const method, so cannot change m_cursor. On the other, it returns a
<br>mutable object of another type, whose methods may not be inline, and I
<br>doubt the compiler can statically prove that methods called on the othe=
r
<br>object can&#39;t modify (in this example) m_cursor. (Certainly I could
<br>readily contrive a pathological example that does exactly that in a way
<br>that the compiler can&#39;t detect.)
<br>
<br>So... ah, yeah. Ick. I *was* ambivalent as to this proposal, until that
<br>example. Now I&#39;m not thrilled with it myself...
<br>
<br></blockquote><div><br>If the evaluation order were only guaranteed for =
certain operators, - would likely not be one of them.<br><br> <span style=
=3D"color:rgb(167,29,93)">int</span> n =3D <span style=3D"color:rgb(0,134,1=
79)">textLayout</span>()-&gt;<span style=3D"color:rgb(0,134,179)">nextCurso=
rPositi<wbr>on</span>(m_cursor) - m_cursor;<br><br>In this case, the sequen=
ced-before guarantees would be that the textLayout() function call occurs b=
efore SomeLayoutType::nextCursorPosition().=C2=A0 The reading of m_cursor, =
either for the function parameter or the subtrahend, would be unsequenced r=
elative to the others.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_10325_266474116.1449695298009--
------=_Part_10324_1882835603.1449695298009--

.

This is a multi-part message in MIME format.
--------------010107070502050007030101
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 09/12/2015 15:40, 'Edward Catmur' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas <jmckesson@gmail.com=20
> <mailto:jmckesson@gmail.com>> wrote:
>
>     On Monday, December 7, 2015 at 6:42:52 PM UTC-5, Edward Catmur wrote:
>
>         On 7 Dec 2015 19:58, "Nicol Bolas" <jmck...@gmail.com> wrote:
>         >
>         > On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989
>         wrote:
>         >>
>         >> <snip>
>         >
>         >
>         > Then I guess we're going to have to agree to disagree then.
>         >
>         > I don't buy that the fact that something takes more words to
>         describe inherently makes it meaningfully more complex. I
>         don't accept your idea that changing the language to better
>         fit users expectations is is somehow hiding something from them.
>         >
>         > I don't even understand what "C++ code is being breaking
>         when the rules are changed, not the programs" is supposed to mean=
..
>         >
>         > I don't accept your assertion that changing code to match
>         user's expectations is being unfriendly to experienced users.
>
>         It is when you're violating the expectations of experienced
>         users. Oh sure, performance is not an observable attribute of
>         the abstract machine. But it is a major selling point of C++,
>         and by preventing the compiler performing CSE on loads and
>         dependent subexpressions of the same expression where there
>         syntactically intervenes a possible store, you're forcing
>         experienced users to either do away with separate compilation
>         and type erasure, or go back to performing CSE by hand like in
>         the dark ages.
>
>
>     First... what's wrong with "performing CSE by hand?" It makes it
>     much more clear what's going on. It also encourages you to stop
>     writing giant expressions in your function calls. That sounds like
>     a win in my book.
>
>
> Not if all you're doing is copying reference parameters and member=20
> variables into locals - that's just renaming. Similarly, an expression=20
> can be highly succinct but contain calls to inline functions and=20
> member functions whose contents could be coalesced.
>
>     Second and more importantly, we have seen exactly one case where
>     CSE would be forbidden under these rules that it would have been
>     both allowed and /valid/ before. Namely, where the common
>     sub-expression involving some non-const non-local, with an
>     intervening function call which the compiler /cannot/ prove did
>     not change that non-local.
>
>
> Non-locals are almost always non-const, unless they're actual=20
> compile-time constants; they exist in the imperative subset of C++.=20
> For the intervening function call, even if the compiler can prove the=20
> non-local is not changed, that's not the end of it; the programmer has=20
> to be satisfied that the compiler will always be able to prove it.
>
>     How common is that case?
>
>     If you believe that CSE denial under these rules would
>     /significantly/ reduce performance across C++ applications, then
>     it would surely not be a burdensome task to prove it. If you're
>     right, then in a codebase of significant size, there must be
>     dozens of places where CSE was validly employed under the old
>     rules, yet it could not be employed under these.
>
>     Show us. Make a case with genuine evidence. In a project the size
>     of Qt, for example, how many cases are there where CSE could be
>     employed now but not under the new rules?
>
>
> OK, here's one in Qt, found just by browsing recent commits:=20
> https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad421=
50b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243
>
> int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>
>
> Currently, the loads from m_cursor can be collapsed; in the presence=20
> of fixed evaluation order the LHS subexpression could change the value=20
> of m_cursor so it has to be reloaded.
If any of the subexpression evaluation can change the value of=20
m_coursor, the expression evaluation can not be done on any order and so=20
UB.

With the new proposal, if the compiler can not prove that it can=20
evaluate on any order it evaluates from left to right and the program is=20
well formed.

Am I missing something?

Vicente

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--------------010107070502050007030101
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 text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 09/12/2015 15:40, 'Edward Catmur'
      via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CAJnLdOZrwJe0Z14s2u=3DGB_6v=3DwBSo=3DdaM256KVevgop03Xbs9A@mail.=
gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">On Tue, Dec 8, 2015 at 2:06 PM, Nicol
            Bolas <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmcke=
sson@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);border-left-=
style:solid;padding-left:1ex">On
              Monday, December 7, 2015 at 6:42:52 PM UTC-5, Edward
              Catmur 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);border-left-=
style:solid;padding-left:1ex">
                <p dir=3D"ltr">On 7 Dec 2015 19:58, "Nicol Bolas" &lt;<a
                    moz-do-not-send=3D"true" rel=3D"nofollow"><a class=3D"m=
oz-txt-link-abbreviated" href=3D"mailto:jmck...@gmail.com">jmck...@gmail.co=
m</a></a>&gt;
                  wrote:<br>
                  &gt;<br>
                  &gt; On Sunday, December 6, 2015 at 9:52:49 PM UTC-5,
                  FrankHB1989 wrote:<br>
                  &gt;&gt;<br>
                  &gt;&gt; &lt;snip&gt;<br>
                  &gt;<br>
                  &gt;<br>
                  &gt; Then I guess we're going to have to agree to
                  disagree then.<br>
                  &gt;<br>
                  &gt; I don't buy that the fact that something takes
                  more words to describe inherently makes it
                  meaningfully more complex. I don't accept your idea
                  that changing the language to better fit users
                  expectations is is somehow hiding something from them.<br=
>
                  &gt;<br>
                  &gt; I don't even understand what "C++ code is being
                  breaking when the rules are changed, not the programs"
                  is supposed to mean.<br>
                  &gt;<br>
                  &gt; I don't accept your assertion that changing code
                  to match user's expectations is being unfriendly to
                  experienced users.</p>
                <p dir=3D"ltr">It is when you're violating the
                  expectations of experienced users. Oh sure,
                  performance is not an observable attribute of the
                  abstract machine. But it is a major selling point of
                  C++, and by preventing the compiler performing CSE on
                  loads and dependent subexpressions of the same
                  expression where there syntactically intervenes a
                  possible store, you're forcing experienced users to
                  either do away with separate compilation and type
                  erasure, or go back to performing CSE by hand like in
                  the dark ages.</p>
              </blockquote>
              <div><br>
                First... what's wrong with "performing CSE by hand?" It
                makes it much more clear what's going on. It also
                encourages you to stop writing giant expressions in your
                function calls. That sounds like a win in my book.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Not if all you're doing is copying reference parameters
              and member variables into locals - that's just renaming.
              Similarly, an expression can be highly succinct but
              contain calls to inline functions and member functions
              whose contents could be coalesced.</div>
            <div><br>
            </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>Second and more importantly, we have seen exactly one
                case where CSE would be forbidden under these rules that
                it would have been both allowed and <i>valid</i>
                before. Namely, where the common sub-expression
                involving some non-const non-local, with an intervening
                function call which the compiler <i>cannot</i> prove
                did not change that non-local.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Non-locals are almost always non-const, unless they're
              actual compile-time constants; they exist in the
              imperative subset of C++. For the intervening function
              call, even if the compiler can prove the non-local is not
              changed, that's not the end of it; the programmer has to
              be satisfied that the compiler will always be able to
              prove it.</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>How common is that case?<br>
                <br>
                If you believe that CSE denial under these rules would <i>s=
ignificantly</i>
                reduce performance across C++ applications, then it
                would surely not be a burdensome task to prove it. If
                you're right, then in a codebase of significant size,
                there must be dozens of places where CSE was validly
                employed under the old rules, yet it could not be
                employed under these.<br>
                <br>
                Show us. Make a case with genuine evidence. In a project
                the size of Qt, for example, how many cases are there
                where CSE could be employed now but not under the new
                rules?<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>OK, here's one in Qt, found just by browsing recent
              commits:=C2=A0<a moz-do-not-send=3D"true"
href=3D"https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d=
7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243">https://git=
hub.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad42150b0bc03/src/=
widgets/widgets/qwidgetlinecontrol.cpp#L243</a></div>
            <div><br>
            </div>
            <div>
              <table class=3D""
                style=3D"border-collapse:collapse;border-spacing:0px;color:=
rgb(51,51,51);font-family:Helvetica,arial,nimbussansl,liberationsans,freesa=
ns,clean,sans-serif,'Apple
                Color Emoji','Segoe UI Emoji','Segoe UI
                Symbol';font-size:13px;line-height:18.2000007629395px">
                <tbody>
                  <tr>
                  </tr>
                  <tr>
                    <td id=3D"LC243" class=3D"" style=3D"padding:0px 10px;v=
ertical-align:top;font-family:Consolas,'Liberation Mono',Menlo,Courier,mono=
space;font-size:12px;white-space:pre;overflow:visible;word-wrap:normal;back=
ground-color:rgb(248,238,199)">        <span class=3D"" style=3D"color:rgb(=
167,29,93)">int</span> n =3D <span class=3D"" style=3D"color:rgb(0,134,179)=
">textLayout</span>()-&gt;<span class=3D"" style=3D"color:rgb(0,134,179)">n=
extCursorPosition</span>(m_cursor) - m_cursor;</td>
                  </tr>
                  <tr>
                    <td id=3D"L244" class=3D"" style=3D"padding:0px
                      10px;width:50px;min-width:50px;white-space:nowrap;fon=
t-family:Consolas,'Liberation
                      Mono',Menlo,Courier,monospace;font-size:12px;line-hei=
ght:18px;color:rgba(0,0,0,0.298039);vertical-align:top;text-align:right;bor=
der-style:solid;border-color:rgb(238,238,238);border-width:0px
                      1px 0px 0px"><br>
                    </td>
                  </tr>
                </tbody>
              </table>
              <br>
            </div>
            <div>Currently, the loads from m_cursor can be collapsed; in
              the presence of fixed evaluation order the LHS
              subexpression could change the value of m_cursor so it has
              to be reloaded.</div>
          </div>
        </div>
      </div>
    </blockquote>
    If any of the subexpression evaluation can change the value of
    m_coursor, the expression evaluation can not be done on any order
    and so UB. <br>
    <br>
    With the new proposal, if the compiler can not prove that it can
    evaluate on any order it evaluates from left to right and the
    program is well formed.<br>
    <br>
    Am I missing something?<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------010107070502050007030101--

.

This is a multi-part message in MIME format.
--------------000703040701060106030303
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 09/12/2015 22:08, Myriachan a =C3=A9crit :
> On Wednesday, December 9, 2015 at 7:37:37 AM UTC-8, Matthew Woehlke=20
> wrote:
>
>     On 2015-12-09 09:40, 'Edward Catmur' wrote:
>     > On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:
>     >> Show us. Make a case with genuine evidence. In a project the
>     size of Qt,
>     >> for example, how many cases are there where CSE could be
>     employed now but
>     >> not under the new rules?
>     >
>     > OK, here's one in Qt, found just by browsing recent commits:
>     >
>     https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7a=
d42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243
>     <https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7=
ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243>
>
>     >
>     > int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>     > Currently, the loads from m_cursor can be collapsed; in the
>     presence of
>     > fixed evaluation order the LHS subexpression could change the
>     value of
>     > m_cursor so it has to be reloaded.
>
>     I wonder if this example works...? On the one hand, textLayout() is a
>     const method, so cannot change m_cursor. On the other, it returns a
>     mutable object of another type, whose methods may not be inline,
>     and I
>     doubt the compiler can statically prove that methods called on the
>     other
>     object can't modify (in this example) m_cursor. (Certainly I could
>     readily contrive a pathological example that does exactly that in
>     a way
>     that the compiler can't detect.)
>
>     So... ah, yeah. Ick. I *was* ambivalent as to this proposal, until
>     that
>     example. Now I'm not thrilled with it myself...
>
>
> If the evaluation order were only guaranteed for certain operators, -=20
> would likely not be one of them.
>
> int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>
> In this case, the sequenced-before guarantees would be that the=20
> textLayout() function call occurs before=20
> SomeLayoutType::nextCursorPosition().  The reading of m_cursor, either=20
> for the function parameter or the subtrahend, would be unsequenced=20
> relative to the others.
>
Yes this example is troubling. It is natural to think that the value of=20
m_cursor for the two leaves would be the same. But a sequential=20
evaluation could result on different values for m_cursor on the same=20
expression :(

I don't know, while the new rule will make more programs correct as some=20
UB is eliminated, the semantics doesn't match with the mental model.

So maybe we should stay with the current rule and ler the program be=20
ill-formed.

Vicente

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--------------000703040701060106030303
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 text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 09/12/2015 22:08, Myriachan a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:10af8dc4-7ed8-4009-b15f-159f60838dbf@isocpp.org"
      type=3D"cite">On Wednesday, December 9, 2015 at 7:37:37 AM UTC-8,
      Matthew Woehlke wrote:
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On
        2015-12-09 09:40, 'Edward Catmur' wrote:
        <br>
        &gt; On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:
        <br>
        &gt;&gt; Show us. Make a case with genuine evidence. In a
        project the size of Qt,
        <br>
        &gt;&gt; for example, how many cases are there where CSE could
        be employed now but
        <br>
        &gt;&gt; not under the new rules?
        <br>
        &gt; <br>
        &gt; OK, here's one in Qt, found just by browsing recent
        commits:
        <br>
        &gt; <a moz-do-not-send=3D"true"
href=3D"https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d=
7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243"
          target=3D"_blank" rel=3D"nofollow"
          onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%=
3A%2F%2Fgithub.com%2Fqtproject%2Fqtbase%2Fblob%2Ff37ea6c5c61099851d9df57c8d=
7ad42150b0bc03%2Fsrc%2Fwidgets%2Fwidgets%2Fqwidgetlinecontrol.cpp%23L243\46=
sa\75D\46sntz\0751\46usg\75AFQjCNFoYl-9DbQgccgNskoL2PH5Oj4Xkg';return
          true;"
          onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2=
F%2Fgithub.com%2Fqtproject%2Fqtbase%2Fblob%2Ff37ea6c5c61099851d9df57c8d7ad4=
2150b0bc03%2Fsrc%2Fwidgets%2Fwidgets%2Fqwidgetlinecontrol.cpp%23L243\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNFoYl-9DbQgccgNskoL2PH5Oj4Xkg';return
          true;">https://github.com/qtproject/<wbr>qtbase/blob/<wbr>f37ea6c=
5c61099851d9df57c8d7ad4<wbr>2150b0bc03/src/widgets/<wbr>widgets/qwidgetline=
control.<wbr>cpp#L243</a>
        <br>
        &gt; <br>
        &gt; int n =3D textLayout()-&gt;<wbr>nextCursorPosition(m_cursor)
        - m_cursor;
        <br>
        &gt; Currently, the loads from m_cursor can be collapsed; in the
        presence of
        <br>
        &gt; fixed evaluation order the LHS subexpression could change
        the value of
        <br>
        &gt; m_cursor so it has to be reloaded.
        <br>
        <br>
        I wonder if this example works...? On the one hand, textLayout()
        is a
        <br>
        const method, so cannot change m_cursor. On the other, it
        returns a
        <br>
        mutable object of another type, whose methods may not be inline,
        and I
        <br>
        doubt the compiler can statically prove that methods called on
        the other
        <br>
        object can't modify (in this example) m_cursor. (Certainly I
        could
        <br>
        readily contrive a pathological example that does exactly that
        in a way
        <br>
        that the compiler can't detect.)
        <br>
        <br>
        So... ah, yeah. Ick. I *was* ambivalent as to this proposal,
        until that
        <br>
        example. Now I'm not thrilled with it myself...
        <br>
        <br>
      </blockquote>
      <div><br>
        If the evaluation order were only guaranteed for certain
        operators, - would likely not be one of them.<br>
        <br>
        <span style=3D"color:rgb(167,29,93)">int</span> n =3D <span
          style=3D"color:rgb(0,134,179)">textLayout</span>()-&gt;<span
          style=3D"color:rgb(0,134,179)">nextCursorPositi<wbr>on</span>(m_c=
ursor)
        - m_cursor;<br>
        <br>
        In this case, the sequenced-before guarantees would be that the
        textLayout() function call occurs before
        SomeLayoutType::nextCursorPosition().=C2=A0 The reading of m_cursor=
,
        either for the function parameter or the subtrahend, would be
        unsequenced relative to the others.<br>
      </div>
      <br>
    </blockquote>
    Yes this example is troubling. It is natural to think that the value
    of m_cursor for the two leaves would be the same. But a sequential
    evaluation could result on different values for m_cursor on the same
    expression :(<br>
    <br>
    I don't know, while the new rule will make more programs correct as
    some UB is eliminated, the semantics doesn't match with the mental
    model.<br>
    <br>
    So maybe we should stay with the current rule and ler the program be
    ill-formed.<br>
    <br>
    Vicente<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------000703040701060106030303--

.

On Wednesday 09 December 2015 10:37:26 Matthew Woehlke wrote:
> I wonder if this example works...? On the one hand, textLayout() is a
> const method, so cannot change m_cursor

Can the compiler assume that a const-ref parameter will not be modified?

Can the compiler assume that a const method will not modify non-mutable
members?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4_745203056.1449710661330
Content-Type: multipart/alternative;
 boundary="----=_Part_5_1440869478.1449710661330"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8B=E5=8D=8810:40:16=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=
=9A
>
> People have developed their intuition of optimizer friendly code over=20
>>> years, in some cases decades, and you want to throw that all away just =
for=20
>>> the sake of marginally reducing beginner confusion?=20
>>>
>>
>> Have they? I certainly don't base my optimizations on CSE, nor do I writ=
e=20
>> code based on assuming CSE will happen. Indeed, I personally try to=20
>> *avoid* lots of sub-expressions. Part of that is for basic readability,=
=20
>> but part of it is *precisely because* it is undefined. By avoiding=20
>> sub-expressions, I avoid the undefined behavior associated with them.
>>
>
> Are you sure? C++ is sufficiently powerful that a syntactically simple=20
> expression may hide plenty of complexity: implicit conversions, member=20
> variables, reference parameters and captures, and so on. The complexity=
=20
> behind that power is only supportable because the compiler is permitted t=
o=20
> optimize much of it away.
>
> By the way: UB only occurs with multiple stores; I would absolutely agree=
=20
> that any expression involving multiple stores probably needs to be=20
> refactored. The specific issue here is multiple loads.
>
> Not so easy in fact. For example, you missed loads from volatile glvalues=
=20
here.
=20

> =20
>
>> Furthermore, you ignore the benefits of allowing C++ programmers,=20
>> beginners or experienced, to actually rely on the evaluation order of=20
>> subexpressions.
>>
>
> That's really not a benefit. If large, complicated expressions are bad,=
=20
> how much worse are large, complicated expressions with multiple=20
> side-effects?
> =20
>
+1.

Moreover, "unsequenced" or "unspecified order" rule is to be relied to tell=
=20
the readers of the code "you should not rely on any particular order".
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=89 UTC+8=E4=B8=8B=E5=8D=8810:40:16=EF=BC=8CEdward Catmur=E5=86=99=E9=81=
=93=EF=BC=9A<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 class=3D"gmail_quote"><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></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><p dir=3D"ltr"> </p>
<p dir=3D"ltr">People have developed their intuition of optimizer friendly =
code over years, in some cases decades, and you want to throw that all away=
 just for the sake of marginally reducing beginner confusion? <br></p></blo=
ckquote><div><br>Have they? I certainly don&#39;t base my optimizations on =
CSE, nor do I write code based on assuming CSE will happen. Indeed, I perso=
nally try to <i>avoid</i> lots of sub-expressions. Part of that is for basi=
c readability, but part of it is <i>precisely because</i> it is undefined. =
By avoiding sub-expressions, I avoid the undefined behavior associated with=
 them.<br></div></blockquote><div><br></div><div>Are you sure? C++ is suffi=
ciently powerful that a syntactically simple expression may hide plenty of =
complexity: implicit conversions, member variables, reference parameters an=
d captures, and so on. The complexity behind that power is only supportable=
 because the compiler is permitted to optimize much of it away.</div><div><=
br></div><div>By the way: UB only occurs with multiple stores; I would abso=
lutely agree that any expression involving multiple stores probably needs t=
o be refactored. The specific issue here is multiple loads.</div><div><br><=
/div></div></div></div></blockquote><div>Not so easy in fact. For example, =
you missed loads from volatile glvalues here.<br>=C2=A0<br></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"><div><div class=3D"gmai=
l_quote"><div></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-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div>Furthermore, you=
 ignore the benefits of allowing C++ programmers, beginners or experienced,=
 to actually rely on the evaluation order of subexpressions.<br></div></blo=
ckquote><div><br></div><div>That&#39;s really not a benefit. If large, comp=
licated expressions are bad, how much worse are large, complicated expressi=
ons with multiple side-effects?</div><div>=C2=A0</div></div></div></div></b=
lockquote><div>+1.<br><br>Moreover, &quot;unsequenced&quot; or &quot;unspec=
ified order&quot; rule is to be relied to tell the readers of the code &quo=
t;you should not rely on any particular order&quot;.<br>=C2=A0<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5_1440869478.1449710661330--
------=_Part_4_745203056.1449710661330--

.

------=_Part_0_1720723518.1449711230793
Content-Type: multipart/alternative;
 boundary="----=_Part_1_76082631.1449711230795"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8A=E5=8D=886:19:39=EF=BC=8CVicente J. Botet Escriba=E5=86=99=E9=
=81=93=EF=BC=9A
>
> Le 09/12/2015 15:40, 'Edward Catmur' via ISO C++ Standard - Future=20
> Proposals a =C3=A9crit :
>
> On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Monday, December 7, 2015 at 6:42:52 PM UTC-5, Edward Catmur wrote:=20
>>>
>>> On 7 Dec 2015 19:58, "Nicol Bolas" <jmck...@gmail.com> wrote:
>>> >
>>> > On Sunday, December 6, 2015 at 9:52:49 PM UTC-5, FrankHB1989 wrote:
>>> >>
>>> >> <snip>
>>> >
>>> >
>>> > Then I guess we're going to have to agree to disagree then.
>>> >
>>> > I don't buy that the fact that something takes more words to describe=
=20
>>> inherently makes it meaningfully more complex. I don't accept your idea=
=20
>>> that changing the language to better fit users expectations is is someh=
ow=20
>>> hiding something from them.
>>> >
>>> > I don't even understand what "C++ code is being breaking when the=20
>>> rules are changed, not the programs" is supposed to mean.
>>> >
>>> > I don't accept your assertion that changing code to match user's=20
>>> expectations is being unfriendly to experienced users.
>>>
>>> It is when you're violating the expectations of experienced users. Oh=
=20
>>> sure, performance is not an observable attribute of the abstract machin=
e.=20
>>> But it is a major selling point of C++, and by preventing the compiler=
=20
>>> performing CSE on loads and dependent subexpressions of the same expres=
sion=20
>>> where there syntactically intervenes a possible store, you're forcing=
=20
>>> experienced users to either do away with separate compilation and type=
=20
>>> erasure, or go back to performing CSE by hand like in the dark ages.
>>>
>>
>> First... what's wrong with "performing CSE by hand?" It makes it much=20
>> more clear what's going on. It also encourages you to stop writing giant=
=20
>> expressions in your function calls. That sounds like a win in my book.
>>
>
> Not if all you're doing is copying reference parameters and member=20
> variables into locals - that's just renaming. Similarly, an expression ca=
n=20
> be highly succinct but contain calls to inline functions and member=20
> functions whose contents could be coalesced.
>
> Second and more importantly, we have seen exactly one case where CSE woul=
d=20
>> be forbidden under these rules that it would have been both allowed and=
=20
>> *valid* before. Namely, where the common sub-expression involving some=
=20
>> non-const non-local, with an intervening function call which the compile=
r=20
>> *cannot* prove did not change that non-local.
>>
>
> Non-locals are almost always non-const, unless they're actual compile-tim=
e=20
> constants; they exist in the imperative subset of C++. For the intervenin=
g=20
> function call, even if the compiler can prove the non-local is not change=
d,=20
> that's not the end of it; the programmer has to be satisfied that the=20
> compiler will always be able to prove it.
> =20
>
>> How common is that case?
>>
>> If you believe that CSE denial under these rules would *significantly*=
=20
>> reduce performance across C++ applications, then it would surely not be =
a=20
>> burdensome task to prove it. If you're right, then in a codebase of=20
>> significant size, there must be dozens of places where CSE was validly=
=20
>> employed under the old rules, yet it could not be employed under these.
>>
>> Show us. Make a case with genuine evidence. In a project the size of Qt,=
=20
>> for example, how many cases are there where CSE could be employed now bu=
t=20
>> not under the new rules?
>>
>
> OK, here's one in Qt, found just by browsing recent commits:=20
> https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad421=
50b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243
>
> int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;=20
>
> Currently, the loads from m_cursor can be collapsed; in the presence of=
=20
> fixed evaluation order the LHS subexpression could change the value of=20
> m_cursor so it has to be reloaded.
>
> If any of the subexpression evaluation can change the value of m_coursor,=
=20
> the expression evaluation can not be done on any order and so UB.=20
>
> Yes. (Even there is only one modification to the stored value.)=20

With the new proposal, if the compiler can not prove that it can evaluate=
=20
> on any order it evaluates from left to right and the program is well form=
ed.
>
> You probably wanted saying "not well-defined". Well-formness is not=20
changed by the rule changes.
=20

> Am I missing something?
>
> Vicente
>
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8A=E5=8D=886:19:39=EF=BC=8CVicente J. Botet Escriba=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 text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 09/12/2015 15:40, &#39;Edward Catmur&#39;
      via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div class=3D"gmail_quote">On Tue, Dec 8, 2015 at 2:06 PM, Nicol
            Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"t6x9Rx0wCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">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);border-left-s=
tyle:solid;padding-left:1ex">On
              Monday, December 7, 2015 at 6:42:52 PM UTC-5, Edward
              Catmur 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);border-left=
-style:solid;padding-left:1ex">
                <p dir=3D"ltr">On 7 Dec 2015 19:58, &quot;Nicol Bolas&quot;=
 &lt;<a rel=3D"nofollow"></a><a>jmck...@gmail.com</a>&gt;
                  wrote:<br>
                  &gt;<br>
                  &gt; On Sunday, December 6, 2015 at 9:52:49 PM UTC-5,
                  FrankHB1989 wrote:<br>
                  &gt;&gt;<br>
                  &gt;&gt; &lt;snip&gt;<br>
                  &gt;<br>
                  &gt;<br>
                  &gt; Then I guess we&#39;re going to have to agree to
                  disagree then.<br>
                  &gt;<br>
                  &gt; I don&#39;t buy that the fact that something takes
                  more words to describe inherently makes it
                  meaningfully more complex. I don&#39;t accept your idea
                  that changing the language to better fit users
                  expectations is is somehow hiding something from them.<br=
>
                  &gt;<br>
                  &gt; I don&#39;t even understand what &quot;C++ code is b=
eing
                  breaking when the rules are changed, not the programs&quo=
t;
                  is supposed to mean.<br>
                  &gt;<br>
                  &gt; I don&#39;t accept your assertion that changing code
                  to match user&#39;s expectations is being unfriendly to
                  experienced users.</p>
                <p dir=3D"ltr">It is when you&#39;re violating the
                  expectations of experienced users. Oh sure,
                  performance is not an observable attribute of the
                  abstract machine. But it is a major selling point of
                  C++, and by preventing the compiler performing CSE on
                  loads and dependent subexpressions of the same
                  expression where there syntactically intervenes a
                  possible store, you&#39;re forcing experienced users to
                  either do away with separate compilation and type
                  erasure, or go back to performing CSE by hand like in
                  the dark ages.</p>
              </blockquote>
              <div><br>
                First... what&#39;s wrong with &quot;performing CSE by hand=
?&quot; It
                makes it much more clear what&#39;s going on. It also
                encourages you to stop writing giant expressions in your
                function calls. That sounds like a win in my book.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Not if all you&#39;re doing is copying reference parameter=
s
              and member variables into locals - that&#39;s just renaming.
              Similarly, an expression can be highly succinct but
              contain calls to inline functions and member functions
              whose contents could be coalesced.</div>
            <div><br>
            </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>Second and more importantly, we have seen exactly one
                case where CSE would be forbidden under these rules that
                it would have been both allowed and <i>valid</i>
                before. Namely, where the common sub-expression
                involving some non-const non-local, with an intervening
                function call which the compiler <i>cannot</i> prove
                did not change that non-local.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Non-locals are almost always non-const, unless they&#39;re
              actual compile-time constants; they exist in the
              imperative subset of C++. For the intervening function
              call, even if the compiler can prove the non-local is not
              changed, that&#39;s not the end of it; the programmer has to
              be satisfied that the compiler will always be able to
              prove it.</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-s=
tyle:solid;padding-left:1ex">
              <div>How common is that case?<br>
                <br>
                If you believe that CSE denial under these rules would <i>s=
ignificantly</i>
                reduce performance across C++ applications, then it
                would surely not be a burdensome task to prove it. If
                you&#39;re right, then in a codebase of significant size,
                there must be dozens of places where CSE was validly
                employed under the old rules, yet it could not be
                employed under these.<br>
                <br>
                Show us. Make a case with genuine evidence. In a project
                the size of Qt, for example, how many cases are there
                where CSE could be employed now but not under the new
                rules?<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>OK, here&#39;s one in Qt, found just by browsing recent
              commits:=C2=A0<a href=3D"https://github.com/qtproject/qtbase/=
blob/f37ea6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetli=
necontrol.cpp#L243" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fqtpro=
ject%2Fqtbase%2Fblob%2Ff37ea6c5c61099851d9df57c8d7ad42150b0bc03%2Fsrc%2Fwid=
gets%2Fwidgets%2Fqwidgetlinecontrol.cpp%23L243\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNFoYl-9DbQgccgNskoL2PH5Oj4Xkg&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fqtproject=
%2Fqtbase%2Fblob%2Ff37ea6c5c61099851d9df57c8d7ad42150b0bc03%2Fsrc%2Fwidgets=
%2Fwidgets%2Fqwidgetlinecontrol.cpp%23L243\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNFoYl-9DbQgccgNskoL2PH5Oj4Xkg&#39;;return true;">https://github.com/<wbr>=
qtproject/qtbase/blob/<wbr>f37ea6c5c61099851d9df57c8d7ad4<wbr>2150b0bc03/sr=
c/widgets/<wbr>widgets/qwidgetlinecontrol.<wbr>cpp#L243</a></div>
            <div><br>
            </div>
            <div>
              <table>
                <tbody>
                  <tr>
                  </tr>
                  <tr>
                    <td style=3D"padding:0px 10px;vertical-align:top;font-f=
amily:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:=
12px;white-space:pre;overflow:visible;word-wrap:normal;background-color:rgb=
(248,238,199)">        <span style=3D"color:rgb(167,29,93)">int</span> n =
=3D <span style=3D"color:rgb(0,134,179)">textLayout</span>()-&gt;<span styl=
e=3D"color:rgb(0,134,179)">nextCursorPositi<wbr>on</span>(m_cursor) - m_cur=
sor;</td>
                  </tr>
                  <tr>
                    <td><br>
                    </td>
                  </tr>
                </tbody>
              </table>
              <br>
            </div>
            <div>Currently, the loads from m_cursor can be collapsed; in
              the presence of fixed evaluation order the LHS
              subexpression could change the value of m_cursor so it has
              to be reloaded.</div>
          </div>
        </div>
      </div>
    </blockquote>
    If any of the subexpression evaluation can change the value of
    m_coursor, the expression evaluation can not be done on any order
    and so UB. <br>
    <br></div></blockquote><div>Yes. (Even there is only one modification t=
o the stored value.) <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 text=3D"#000000" bgcolor=3D"#FFFFFF">
    With the new proposal, if the compiler can not prove that it can
    evaluate on any order it evaluates from left to right and the
    program is well formed.<br>
    <br></div></blockquote><div>You probably wanted saying &quot;not well-d=
efined&quot;. Well-formness is not changed by the rule changes.<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 text=3D"#000000" =
bgcolor=3D"#FFFFFF">
    Am I missing something?<br>
    <br>
    Vicente<br></div></blockquote><div>=C2=A0</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1_76082631.1449711230795--
------=_Part_0_1720723518.1449711230793--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">For languages (C#, java, etc) where the order is more fully def=
ined, what do typical coding guidelines have to say? Are certain patterns (=
ie code that might be unordered in C++) discouraged?</div>                 =
                                                                           =
                                         <div style=3D"width: 100%; font-si=
ze: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; col=
or: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, =
255);"><br style=3D"display:initial"></div>                                =
                                                                           =
                                                                           =
             <div style=3D"font-size: initial; font-family: Calibri, 'Slate=
 Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial=
; background-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackB=
erry&nbsp;portable&nbsp;Babbage&nbsp;Device</div>                          =
                                                                           =
                                                                           =
  <table width=3D"100%" style=3D"background-color:white;border-spacing:0px;=
"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: in=
itial; background-color: rgb(255, 255, 255);">                           <d=
iv style=3D"border-style: solid none none; border-top-color: rgb(181, 196, =
223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB=
 Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>FrankHB198=
9</div><div><b>Sent: </b>Wednesday, December 9, 2015 8:24 PM</div><div><b>T=
o: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b>std-p=
roposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] About ord=
er of evaluation</div></div></td></tr></tbody></table><div style=3D"border-=
style: solid none none; border-top-color: rgb(186, 188, 209); border-top-wi=
dth: 1pt; font-size: initial; text-align: initial; background-color: rgb(25=
5, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><br><br>=
=E5=9C=A8 2015=E5=B9=B412=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8B=E5=8D=8810:40:16=EF=BC=8CEdward Catmur=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"><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></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir=
=3D"ltr"> </p>
<p dir=3D"ltr">People have developed their intuition of optimizer friendly =
code over years, in some cases decades, and you want to throw that all away=
 just for the sake of marginally reducing beginner confusion? <br></p></blo=
ckquote><div><br>Have they? I certainly don't base my optimizations on CSE,=
 nor do I write code based on assuming CSE will happen. Indeed, I personall=
y try to <i>avoid</i> lots of sub-expressions. Part of that is for basic re=
adability, but part of it is <i>precisely because</i> it is undefined. By a=
voiding sub-expressions, I avoid the undefined behavior associated with the=
m.<br></div></blockquote><div><br></div><div>Are you sure? C++ is sufficien=
tly powerful that a syntactically simple expression may hide plenty of comp=
lexity: implicit conversions, member variables, reference parameters and ca=
ptures, and so on. The complexity behind that power is only supportable bec=
ause the compiler is permitted to optimize much of it away.</div><div><br><=
/div><div>By the way: UB only occurs with multiple stores; I would absolute=
ly agree that any expression involving multiple stores probably needs to be=
 refactored. The specific issue here is multiple loads.</div><div><br></div=
></div></div></div></blockquote><div>Not so easy in fact. For example, you =
missed loads from volatile glvalues here.<br>&nbsp;<br></div><blockquote cl=
ass=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_qu=
ote"><div></div><div>&nbsp;</div><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>Furthermore, you ign=
ore the benefits of allowing C++ programmers, beginners or experienced, to =
actually rely on the evaluation order of subexpressions.<br></div></blockqu=
ote><div><br></div><div>That's really not a benefit. If large, complicated =
expressions are bad, how much worse are large, complicated expressions with=
 multiple side-effects?</div><div>&nbsp;</div></div></div></div></blockquot=
e><div>+1.<br><br>Moreover, "unsequenced" or "unspecified order" rule is to=
 be relied to tell the readers of the code "you should not rely on any part=
icular order".<br>&nbsp;<br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

.

------=_Part_4_625057380.1449711443085
Content-Type: multipart/alternative;
 boundary="----=_Part_5_2029930122.1449711443085"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=E5=86=99=E9=
=81=93=EF=BC=9A
>
> Le 09/12/2015 22:08, Myriachan a =C3=A9crit :
>
> On Wednesday, December 9, 2015 at 7:37:37 AM UTC-8, Matthew Woehlke wrote=
:=20
>>
>> On 2015-12-09 09:40, 'Edward Catmur' wrote:=20
>> > On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:=20
>> >> Show us. Make a case with genuine evidence. In a project the size of=
=20
>> Qt,=20
>> >> for example, how many cases are there where CSE could be employed now=
=20
>> but=20
>> >> not under the new rules?=20
>> >=20
>> > OK, here's one in Qt, found just by browsing recent commits:=20
>> >=20
>> https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad42=
150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243=20
>> >=20
>> > int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;=20
>> > Currently, the loads from m_cursor can be collapsed; in the presence o=
f=20
>> > fixed evaluation order the LHS subexpression could change the value of=
=20
>> > m_cursor so it has to be reloaded.=20
>>
>> I wonder if this example works...? On the one hand, textLayout() is a=20
>> const method, so cannot change m_cursor. On the other, it returns a=20
>> mutable object of another type, whose methods may not be inline, and I=
=20
>> doubt the compiler can statically prove that methods called on the other=
=20
>> object can't modify (in this example) m_cursor. (Certainly I could=20
>> readily contrive a pathological example that does exactly that in a way=
=20
>> that the compiler can't detect.)=20
>>
>> So... ah, yeah. Ick. I *was* ambivalent as to this proposal, until that=
=20
>> example. Now I'm not thrilled with it myself...=20
>>
>>
> If the evaluation order were only guaranteed for certain operators, -=20
> would likely not be one of them.
>
> int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>
> In this case, the sequenced-before guarantees would be that the=20
> textLayout() function call occurs before=20
> SomeLayoutType::nextCursorPosition().  The reading of m_cursor, either fo=
r=20
> the function parameter or the subtrahend, would be unsequenced relative t=
o=20
> the others.
>
> Yes this example is troubling. It is natural to think that the value of=
=20
> m_cursor for the two leaves would be the same. But a sequential evaluatio=
n=20
> could result on different values for m_cursor on the same expression :(
>
> I don't know, while the new rule will make more programs correct as some=
=20
> UB is eliminated, the semantics doesn't match with the mental model.
>
> I believe it would be worse, whether the original code is buggy or not.=
=20
This is one reason that I am against the change.
=20

> So maybe we should stay with the current rule and ler the program be=20
> ill-formed.
>
> As said, this is not ill-formed. Just UB.
=20

> Vicente
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=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 text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 09/12/2015 22:08, Myriachan a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">On Wednesday, December 9, 2015 at 7:37:37 AM =
UTC-8,
      Matthew Woehlke wrote:
      <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">On
        2015-12-09 09:40, &#39;Edward Catmur&#39; wrote:
        <br>
        &gt; On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:
        <br>
        &gt;&gt; Show us. Make a case with genuine evidence. In a
        project the size of Qt,
        <br>
        &gt;&gt; for example, how many cases are there where CSE could
        be employed now but
        <br>
        &gt;&gt; not under the new rules?
        <br>
        &gt; <br>
        &gt; OK, here&#39;s one in Qt, found just by browsing recent
        commits:
        <br>
        &gt; <a href=3D"https://github.com/qtproject/qtbase/blob/f37ea6c5c6=
1099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L=
243" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;htt=
ps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fqtproject%2Fqtbase%2=
Fblob%2Ff37ea6c5c61099851d9df57c8d7ad42150b0bc03%2Fsrc%2Fwidgets%2Fwidgets%=
2Fqwidgetlinecontrol.cpp%23L243\46sa\75D\46sntz\0751\46usg\75AFQjCNFoYl-9Db=
QgccgNskoL2PH5Oj4Xkg&#39;;return true;" onclick=3D"this.href=3D&#39;https:/=
/www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fqtproject%2Fqtbase%2Fblo=
b%2Ff37ea6c5c61099851d9df57c8d7ad42150b0bc03%2Fsrc%2Fwidgets%2Fwidgets%2Fqw=
idgetlinecontrol.cpp%23L243\46sa\75D\46sntz\0751\46usg\75AFQjCNFoYl-9DbQgcc=
gNskoL2PH5Oj4Xkg&#39;;return true;">https://github.com/qtproject/<wbr>qtbas=
e/blob/<wbr>f37ea6c5c61099851d9df57c8d7ad4<wbr>2150b0bc03/src/widgets/<wbr>=
widgets/qwidgetlinecontrol.<wbr>cpp#L243</a>
        <br>
        &gt; <br>
        &gt; int n =3D textLayout()-&gt;<wbr>nextCursorPosition(m_cursor)
        - m_cursor;
        <br>
        &gt; Currently, the loads from m_cursor can be collapsed; in the
        presence of
        <br>
        &gt; fixed evaluation order the LHS subexpression could change
        the value of
        <br>
        &gt; m_cursor so it has to be reloaded.
        <br>
        <br>
        I wonder if this example works...? On the one hand, textLayout()
        is a
        <br>
        const method, so cannot change m_cursor. On the other, it
        returns a
        <br>
        mutable object of another type, whose methods may not be inline,
        and I
        <br>
        doubt the compiler can statically prove that methods called on
        the other
        <br>
        object can&#39;t modify (in this example) m_cursor. (Certainly I
        could
        <br>
        readily contrive a pathological example that does exactly that
        in a way
        <br>
        that the compiler can&#39;t detect.)
        <br>
        <br>
        So... ah, yeah. Ick. I *was* ambivalent as to this proposal,
        until that
        <br>
        example. Now I&#39;m not thrilled with it myself...
        <br>
        <br>
      </blockquote>
      <div><br>
        If the evaluation order were only guaranteed for certain
        operators, - would likely not be one of them.<br>
        <br>
        <span style=3D"color:rgb(167,29,93)">int</span> n =3D <span style=
=3D"color:rgb(0,134,179)">textLayout</span>()-&gt;<span style=3D"color:rgb(=
0,134,179)">nextCursorPositi<wbr>on</span>(m_cursor)
        - m_cursor;<br>
        <br>
        In this case, the sequenced-before guarantees would be that the
        textLayout() function call occurs before
        SomeLayoutType::<wbr>nextCursorPosition().=C2=A0 The reading of m_c=
ursor,
        either for the function parameter or the subtrahend, would be
        unsequenced relative to the others.<br>
      </div>
      <br>
    </blockquote>
    Yes this example is troubling. It is natural to think that the value
    of m_cursor for the two leaves would be the same. But a sequential
    evaluation could result on different values for m_cursor on the same
    expression :(<br>
    <br>
    I don&#39;t know, while the new rule will make more programs correct as
    some UB is eliminated, the semantics doesn&#39;t match with the mental
    model.<br>
    <br></div></blockquote><div>I believe it would be worse, whether the or=
iginal code is buggy or not. This is one reason that I am against the chang=
e.<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 tex=
t=3D"#000000" bgcolor=3D"#FFFFFF">
    So maybe we should stay with the current rule and ler the program be
    ill-formed.<br>
    <br></div></blockquote><div>As said, this is not ill-formed. Just UB.<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 text=3D=
"#000000" bgcolor=3D"#FFFFFF">
    Vicente<br>
    <br>
  </div>

</blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5_2029930122.1449711443085--
------=_Part_4_625057380.1449711443085--

.

------=_Part_4_1529249968.1449712385359
Content-Type: multipart/alternative;
 boundary="----=_Part_5_948832730.1449712385360"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8A=E5=8D=889:34:35=EF=BC=8CTony V E=E5=86=99=E9=81=93=EF=BC=9A
>
> For languages (C#, java, etc) where the order is more fully defined, what=
=20
> do typical coding guidelines have to say? Are certain patterns (ie code=
=20
> that might be unordered in C++) discouraged?
>
>
> As I experienced (though I did not write much Java or C# code), yes.

And I've mentioned the Java Language Specification suggest to not write=20
such code immediately after the rules. Perhaps better to recite again:

From the Java Language Specification 8:

*15.7 Evaluation Order*
>
> The Java programming language guarantees that the operands of operators=
=20
> appear
> to be evaluated in a specific evaluation order, namely, from left to righ=
t.
>
> It is recommended that code not rely crucially on this specification. Cod=
e=20
> is usually clearer
> when each expression contains at most one side effect, as its outermost=
=20
> operation, and when
> code does not depend on exactly which exception arises as a consequence o=
f=20
> the left-to-right
> evaluation of expressions.
>

BTW, the "left-to-right evaluation rule" occurs more than once in the=20
specification, e.g:

*15.7.4 Argument Lists are Evaluated Left-to-Right*
> In a method or constructor invocation or class instance creation=20
> expression,
> argument expressions may appear within the parentheses, separated by=20
> commas.
> Each argument expression appears to be fully evaluated before any part of=
=20
> any
> argument expression to its right.
> If evaluation of an argument expression completes abruptly, no part of an=
y
> argument expression to its right appears to have been evaluated.
>

and


> *15.9.4 Run-Time Evaluation of Class Instance Creation Expressions*...
> Next, the actual arguments to the constructor are evaluated,=20
> left-to-right. If any of
> the argument evaluations completes abruptly, any argument expressions to=
=20
> its right
> are not evaluated, and the class instance creation expression completes=
=20
> abruptly for
> the same reason.
> ...
>

I don't think it is a good style as a 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8A=E5=8D=889:34:35=EF=BC=8CTony V E=E5=86=99=E9=81=93=EF=
=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"background=
-color:rgb(255,255,255);line-height:initial" lang=3D"en-US">               =
                                                                       <div=
 style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#=
39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgroun=
d-color:rgb(255,255,255)">For languages (C#, java, etc) where the order is =
more fully defined, what do typical coding guidelines have to say? Are cert=
ain patterns (ie code that might be unordered in C++) discouraged?</div>   =
                                                                           =
                                                       <div style=3D"width:=
100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,s=
ans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,=
255,255)"><br style=3D"display:initial"></div><br></div></blockquote><div>A=
s I experienced (though I did not write much Java or C# code), yes.<br><br>=
And I&#39;ve mentioned the Java Language Specification suggest to not write=
 such code immediately after the rules. Perhaps better to recite again:<br>=
<br>From the Java Language Specification 8:<br><br><blockquote style=3D"mar=
gin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-=
left: 1ex;" class=3D"gmail_quote"><b>15.7 Evaluation Order</b><br><br>The J=
ava programming language guarantees that the operands of operators appear<b=
r>to be evaluated in a specific evaluation order, namely, from left to righ=
t.<br><br><div style=3D"margin-left: 40px;">It is recommended that code not=
 rely crucially on this specification. Code is usually clearer<br>when each=
 expression contains at most one side effect, as its outermost operation, a=
nd when<br>code does not depend on exactly which exception arises as a cons=
equence of the left-to-right<br>evaluation of expressions.<br></div></block=
quote><br>BTW, the &quot;left-to-right evaluation rule&quot; occurs more th=
an once in the specification, e.g:<br><br><blockquote style=3D"margin: 0px =
0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex=
;" class=3D"gmail_quote"><b>15.7.4 Argument Lists are Evaluated Left-to-Rig=
ht</b><br>In a method or constructor invocation or class instance creation =
expression,<br>argument expressions may appear within the parentheses, sepa=
rated by commas.<br>Each argument expression appears to be fully evaluated =
before any part of any<br>argument expression to its right.<br>If evaluatio=
n of an argument expression completes abruptly, no part of any<br>argument =
expression to its right appears to have been evaluated.<br></blockquote><br=
>and<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><b>15=
..9.4 Run-Time Evaluation of Class Instance Creation Expressions<br></b>...<=
br>Next, the actual arguments to the constructor are evaluated, left-to-rig=
ht. If any of<br>the argument evaluations completes abruptly, any argument =
expressions to its right<br>are not evaluated, and the class instance creat=
ion expression completes abruptly for<br>the same reason.<br>...<br></block=
quote><br>I don&#39;t think it is a good style as a specification.<br><br><=
/div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5_948832730.1449712385360--
------=_Part_4_1529249968.1449712385359--

.

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

On Thu, Dec 10, 2015 at 1:33 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:

> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B =
UTC+8=E4=B8=8A=E5=8D=886:19:39=EF=BC=8CVicente J. Botet Escriba=E5=86=99=E9=
=81=93=EF=BC=9A
>>
>> Le 09/12/2015 15:40, 'Edward Catmur' via ISO C++ Standard - Future
>> Proposals a =C3=A9crit :
>>
>> int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>> Currently, the loads from m_cursor can be collapsed; in the presence of
>> fixed evaluation order the LHS subexpression could change the value of
>> m_cursor so it has to be reloaded.
>>
>> If any of the subexpression evaluation can change the value of m_coursor=
,
>> the expression evaluation can not be done on any order and so UB.
>>
>> Yes. (Even there is only one modification to the stored value.)
>

This isn't UB. Any modification would occur within the execution of
nextCursorPosition (or textLayout) and so be indeterminately sequenced, not
unsequenced, with the RHS read; [intro.execution]/15.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a113ecb4011acf0052688e7cd
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, Dec 10, 2015 at 1:33 AM, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.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">=E5=9C=A8 2015=E5=B9=B412=
=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=886:19=
:39=EF=BC=8CVicente J. Botet Escriba=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 text=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D"">
    <div>Le 09/12/2015 15:40, &#39;Edward Catmur&#39;
      via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
    </div>
    </span><span class=3D""><blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div class=3D"gmail_quote"><div><table>
                <tbody>
                  <tr>
                  </tr>
                  <tr>
                    <td style=3D"padding:0px 10px;vertical-align:top;font-f=
amily:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:=
12px;white-space:pre-wrap;overflow:visible;word-wrap:normal;background-colo=
r:rgb(248,238,199)">        <span style=3D"color:rgb(167,29,93)">int</span>=
 n =3D <span style=3D"color:rgb(0,134,179)">textLayout</span>()-&gt;<span s=
tyle=3D"color:rgb(0,134,179)">nextCursorPosition</span>(m_cursor) - m_curso=
r;</td>
                  </tr>
                  <tr>
                    <td><br>
                    </td>
                  </tr>
                </tbody>
              </table>
              </div><div>Currently, the loads from m_cursor can be collapse=
d; in
              the presence of fixed evaluation order the LHS
              subexpression could change the value of m_cursor so it has
              to be reloaded.</div>
          </div>
        </div>
      </div>
    </blockquote>
    If any of the subexpression evaluation can change the value of
    m_coursor, the expression evaluation can not be done on any order
    and so UB. <br>
    <br></span></div></blockquote><div>Yes. (Even there is only one modific=
ation to the stored value.) <br></div></blockquote><div><br></div><div>This=
 isn&#39;t UB. Any modification would occur within the execution of nextCur=
sorPosition (or textLayout) and so be indeterminately sequenced, not unsequ=
enced, with the RHS read; [intro.execution]/15.</div><div><br></div></div><=
/div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ecb4011acf0052688e7cd--

.

On 2015-12-09 19:35, Thiago Macieira wrote:
> On Wednesday 09 December 2015 10:37:26 Matthew Woehlke wrote:
>> I wonder if this example works...? On the one hand, textLayout() is a
>> const method, so cannot change m_cursor
>=20
> Can the compiler assume that a const-ref parameter will not be modified?

*Directly*? AFAIK, yes. IIRC it's even UB to modify a const (of unknown
pedigree), period. I *want* to say there are exceptions (otherwise *any*
use of const_cast would be UB), but they're just that... exceptions.

> Can the compiler assume that a const method will not modify non-mutable=
=20
> members?

*Directly*? Again, I would guess so. However the example given calls a
method on another object for which (I believe=C2=B9) the compiler does not
have a definition. That method could do anything, including call a
non-const method on the original object that is held as a mutable
pointer by the second object (or even globally). In short, once an
external=C2=B2 function is called, all bets are off.

(=C2=B9 And if it does in that exact example, let's assume for the sake of
the hypothetical situation that it doesn't.)

(=C2=B2 This can be mitigated if the external function is e.g. [[pure]], bu=
t
I believe that was not the case in the example given.)

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

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

On Thu, Dec 10, 2015 at 3:25 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-12-09 19:35, Thiago Macieira wrote:
> > On Wednesday 09 December 2015 10:37:26 Matthew Woehlke wrote:
> >> I wonder if this example works...? On the one hand, textLayout() is a
> >> const method, so cannot change m_cursor
> >
> > Can the compiler assume that a const-ref parameter will not be modified=
?
>
> *Directly*? AFAIK, yes. IIRC it's even UB to modify a const (of unknown
> pedigree), period. I *want* to say there are exceptions (otherwise *any*
> use of const_cast would be UB), but they're just that... exceptions.
>

It's only UB if the object referenced by the parameter is actually const
(that is, the cv-qualifiers on its type at its point of declaration contain
const).


> > Can the compiler assume that a const method will not modify non-mutable
> > members?
>
> *Directly*? Again, I would guess so. However the example given calls a
> method on another object for which (I believe=C2=B9) the compiler does no=
t
> have a definition. That method could do anything, including call a
> non-const method on the original object that is held as a mutable
> pointer by the second object (or even globally). In short, once an
> external=C2=B2 function is called, all bets are off.
>

Again, no; it can be UB to const_cast away const on this if the object is
actually const, but otherwise it is legit. So, calling an opaque
const-qualified member function on a non-const object may well modify
members (as long as they themselves are not declared const).

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a113dfbd61b2e0205268dd4fe
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, Dec 10, 2015 at 3:25 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><span class=3D"">On 2015-12-=
09 19:35, Thiago Macieira wrote:<br>
&gt; On Wednesday 09 December 2015 10:37:26 Matthew Woehlke wrote:<br>
&gt;&gt; I wonder if this example works...? On the one hand, textLayout() i=
s a<br>
&gt;&gt; const method, so cannot change m_cursor<br>
&gt;<br>
&gt; Can the compiler assume that a const-ref parameter will not be modifie=
d?<br>
<br>
</span>*Directly*? AFAIK, yes. IIRC it&#39;s even UB to modify a const (of =
unknown<br>
pedigree), period. I *want* to say there are exceptions (otherwise *any*<br=
>
use of const_cast would be UB), but they&#39;re just that... exceptions.<sp=
an class=3D""><br></span></blockquote><div><br></div><div>It&#39;s only UB =
if the object referenced by the parameter is actually const (that is, the c=
v-qualifiers on its type at its point of declaration contain const).</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-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><span class=3D"">
&gt; Can the compiler assume that a const method will not modify non-mutabl=
e<br>
&gt; members?<br>
<br>
</span>*Directly*? Again, I would guess so. However the example given calls=
 a<br>
method on another object for which (I believe=C2=B9) the compiler does not<=
br>
have a definition. That method could do anything, including call a<br>
non-const method on the original object that is held as a mutable<br>
pointer by the second object (or even globally). In short, once an<br>
external=C2=B2 function is called, all bets are off.<br></blockquote><div><=
br></div><div>Again, no; it can be UB to const_cast away const on this if t=
he object is actually const, but otherwise it is legit. So, calling an opaq=
ue const-qualified member function on a non-const object may well modify me=
mbers (as long as they themselves are not declared const).</div></div></div=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113dfbd61b2e0205268dd4fe--

.

This is a multi-part message in MIME format.
--------------070102060301020109050304
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 10/12/2015 02:37, FrankHB1989 a =C3=A9crit :
>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B =
UTC+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=E5=86=99=E9=
=81=93=EF=BC=9A
>
>     Le 09/12/2015 22:08, Myriachan a =C3=A9crit :
>>     On Wednesday, December 9, 2015 at 7:37:37 AM UTC-8, Matthew
>>     Woehlke wrote:
>>
>>         On 2015-12-09 09:40, 'Edward Catmur' wrote:
>>         > On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:
>>         >> Show us. Make a case with genuine evidence. In a project
>>         the size of Qt,
>>         >> for example, how many cases are there where CSE could be
>>         employed now but
>>         >> not under the new rules?
>>         >
>>         > OK, here's one in Qt, found just by browsing recent commits:
>>         >
>>         https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57=
c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243
>>         <https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df5=
7c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243>
>>
>>         >
>>         > int n =3D textLayout()->nextCursorPosition(m_cursor) - m_curso=
r;
>>         > Currently, the loads from m_cursor can be collapsed; in the
>>         presence of
>>         > fixed evaluation order the LHS subexpression could change
>>         the value of
>>         > m_cursor so it has to be reloaded.
>>
>>         I wonder if this example works...? On the one hand,
>>         textLayout() is a
>>         const method, so cannot change m_cursor. On the other, it
>>         returns a
>>         mutable object of another type, whose methods may not be
>>         inline, and I
>>         doubt the compiler can statically prove that methods called
>>         on the other
>>         object can't modify (in this example) m_cursor. (Certainly I
>>         could
>>         readily contrive a pathological example that does exactly
>>         that in a way
>>         that the compiler can't detect.)
>>
>>         So... ah, yeah. Ick. I *was* ambivalent as to this proposal,
>>         until that
>>         example. Now I'm not thrilled with it myself...
>>
>>
>>     If the evaluation order were only guaranteed for certain
>>     operators, - would likely not be one of them.
>>
>>     int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>>
>>     In this case, the sequenced-before guarantees would be that the
>>     textLayout() function call occurs before
>>     SomeLayoutType::nextCursorPosition().  The reading of m_cursor,
>>     either for the function parameter or the subtrahend, would be
>>     unsequenced relative to the others.
>>
>     Yes this example is troubling. It is natural to think that the
>     value of m_cursor for the two leaves would be the same. But a
>     sequential evaluation could result on different values for
>     m_cursor on the same expression :(
>
>     I don't know, while the new rule will make more programs correct
>     as some UB is eliminated, the semantics doesn't match with the
>     mental model.
>
> I believe it would be worse, whether the original code is buggy or=20
> not. This is one reason that I am against the change.
>
>     So maybe we should stay with the current rule and ler the program
>     be ill-formed.
>
> As said, this is not ill-formed. Just UB.
>
>
yes, this is what I wanted to say.

Vicente

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--------------070102060301020109050304
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 text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 10/12/2015 02:37, FrankHB1989 a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:77d866e9-7268-4a70-8549-960b829978f7@isocpp.org"
      type=3D"cite"><br>
      <br>
      =E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=
=9B UTC+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=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 text=3D"#000000" bgcolor=3D"#FFFFFF">
          <div>Le 09/12/2015 22:08, Myriachan a =C3=A9crit=C2=A0:<br>
          </div>
          <blockquote type=3D"cite">On Wednesday, December 9, 2015 at
            7:37:37 AM UTC-8, Matthew Woehlke wrote:
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">On 2015-12-09 09:40, 'Edward
              Catmur' wrote: <br>
              &gt; On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote: <br>
              &gt;&gt; Show us. Make a case with genuine evidence. In a
              project the size of Qt, <br>
              &gt;&gt; for example, how many cases are there where CSE
              could be employed now but <br>
              &gt;&gt; not under the new rules? <br>
              &gt; <br>
              &gt; OK, here's one in Qt, found just by browsing recent
              commits: <br>
              &gt; <a moz-do-not-send=3D"true"
href=3D"https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d=
7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243"
                rel=3D"nofollow" target=3D"_blank"
                onmousedown=3D"this.href=3D'https://www.google.com/url?q\75=
https%3A%2F%2Fgithub.com%2Fqtproject%2Fqtbase%2Fblob%2Ff37ea6c5c61099851d9d=
f57c8d7ad42150b0bc03%2Fsrc%2Fwidgets%2Fwidgets%2Fqwidgetlinecontrol.cpp%23L=
243\46sa\75D\46sntz\0751\46usg\75AFQjCNFoYl-9DbQgccgNskoL2PH5Oj4Xkg';return
                true;"
                onclick=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fgithub.com%2Fqtproject%2Fqtbase%2Fblob%2Ff37ea6c5c61099851d9df57c=
8d7ad42150b0bc03%2Fsrc%2Fwidgets%2Fwidgets%2Fqwidgetlinecontrol.cpp%23L243\=
46sa\75D\46sntz\0751\46usg\75AFQjCNFoYl-9DbQgccgNskoL2PH5Oj4Xkg';return
                true;">https://github.com/qtproject/<wbr>qtbase/blob/<wbr>f=
37ea6c5c61099851d9df57c8d7ad4<wbr>2150b0bc03/src/widgets/<wbr>widgets/qwidg=
etlinecontrol.<wbr>cpp#L243</a>
              <br>
              &gt; <br>
              &gt; int n =3D textLayout()-&gt;<wbr>nextCursorPosition(m_cur=
sor)

              - m_cursor; <br>
              &gt; Currently, the loads from m_cursor can be collapsed;
              in the presence of <br>
              &gt; fixed evaluation order the LHS subexpression could
              change the value of <br>
              &gt; m_cursor so it has to be reloaded. <br>
              <br>
              I wonder if this example works...? On the one hand,
              textLayout() is a <br>
              const method, so cannot change m_cursor. On the other, it
              returns a <br>
              mutable object of another type, whose methods may not be
              inline, and I <br>
              doubt the compiler can statically prove that methods
              called on the other <br>
              object can't modify (in this example) m_cursor. (Certainly
              I could <br>
              readily contrive a pathological example that does exactly
              that in a way <br>
              that the compiler can't detect.) <br>
              <br>
              So... ah, yeah. Ick. I *was* ambivalent as to this
              proposal, until that <br>
              example. Now I'm not thrilled with it myself... <br>
              <br>
            </blockquote>
            <div><br>
              If the evaluation order were only guaranteed for certain
              operators, - would likely not be one of them.<br>
              <br>
              <span style=3D"color:rgb(167,29,93)">int</span> n =3D <span
                style=3D"color:rgb(0,134,179)">textLayout</span>()-&gt;<spa=
n
                style=3D"color:rgb(0,134,179)">nextCursorPositi<wbr>on</spa=
n>(m_cursor)

              - m_cursor;<br>
              <br>
              In this case, the sequenced-before guarantees would be
              that the textLayout() function call occurs before
              SomeLayoutType::<wbr>nextCursorPosition().=C2=A0 The reading =
of
              m_cursor, either for the function parameter or the
              subtrahend, would be unsequenced relative to the others.<br>
            </div>
            <br>
          </blockquote>
          Yes this example is troubling. It is natural to think that the
          value of m_cursor for the two leaves would be the same. But a
          sequential evaluation could result on different values for
          m_cursor on the same expression :(<br>
          <br>
          I don't know, while the new rule will make more programs
          correct as some UB is eliminated, the semantics doesn't match
          with the mental model.<br>
          <br>
        </div>
      </blockquote>
      <div>I believe it would be worse, whether the original code is
        buggy or not. This is one reason that I am against the change.<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 text=3D"#000000" bgcolor=3D"#FFFFFF"> So maybe we should stay
          with the current rule and ler the program be ill-formed.<br>
          <br>
        </div>
      </blockquote>
      <div>As said, this is not ill-formed. Just UB.<br>
        =C2=A0<br>
      </div>
      <br>
    </blockquote>
    yes, this is what I wanted to say. <br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------070102060301020109050304--

.

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

So as you can see, people in this discussion looking at the Qt expression
are confused as to whether its behavior is undefined or unspecified.  Which
has always been my point.  Presumably people participating in this
discussion are experts (at least to some extent), and yet even they get
this sort of thing wrong.

"Frank HB", who argued that "a programmer who don't have enough common
sense about sequence rules (also imply the definition of "undefined
behavior"), should not be granted permission of modify the C++ code base in
a serious project" must presumably now include himself in his ban, since he
replied to "If any of the subexpression evaluation can change the value of
m_coursor, the expression evaluation can not be done on any order and so
UB." with "Yes. (Even there is only one modification to the stored value.) =
"


On Thu, Dec 10, 2015 at 5:26 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> Le 10/12/2015 02:37, FrankHB1989 a =C3=A9crit :
>
>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B =
UTC+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=E5=86=99=E9=
=81=93=EF=BC=9A
>>
>> Le 09/12/2015 22:08, Myriachan a =C3=A9crit :
>>
>> On Wednesday, December 9, 2015 at 7:37:37 AM UTC-8, Matthew Woehlke
>> wrote:
>>>
>>> On 2015-12-09 09:40, 'Edward Catmur' wrote:
>>> > On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:
>>> >> Show us. Make a case with genuine evidence. In a project the size of
>>> Qt,
>>> >> for example, how many cases are there where CSE could be employed no=
w
>>> but
>>> >> not under the new rules?
>>> >
>>> > OK, here's one in Qt, found just by browsing recent commits:
>>> >
>>> https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad4=
2150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243
>>> >
>>> > int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>>> > Currently, the loads from m_cursor can be collapsed; in the presence
>>> of
>>> > fixed evaluation order the LHS subexpression could change the value o=
f
>>> > m_cursor so it has to be reloaded.
>>>
>>> I wonder if this example works...? On the one hand, textLayout() is a
>>> const method, so cannot change m_cursor. On the other, it returns a
>>> mutable object of another type, whose methods may not be inline, and I
>>> doubt the compiler can statically prove that methods called on the othe=
r
>>> object can't modify (in this example) m_cursor. (Certainly I could
>>> readily contrive a pathological example that does exactly that in a way
>>> that the compiler can't detect.)
>>>
>>> So... ah, yeah. Ick. I *was* ambivalent as to this proposal, until that
>>> example. Now I'm not thrilled with it myself...
>>>
>>>
>> If the evaluation order were only guaranteed for certain operators, -
>> would likely not be one of them.
>>
>> int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>>
>> In this case, the sequenced-before guarantees would be that the
>> textLayout() function call occurs before
>> SomeLayoutType::nextCursorPosition().  The reading of m_cursor, either f=
or
>> the function parameter or the subtrahend, would be unsequenced relative =
to
>> the others.
>>
>> Yes this example is troubling. It is natural to think that the value of
>> m_cursor for the two leaves would be the same. But a sequential evaluati=
on
>> could result on different values for m_cursor on the same expression :(
>>
>> I don't know, while the new rule will make more programs correct as some
>> UB is eliminated, the semantics doesn't match with the mental model.
>>
>> I believe it would be worse, whether the original code is buggy or not.
> This is one reason that I am against the change.
>
>
>> So maybe we should stay with the current rule and ler the program be
>> ill-formed.
>>
>> As said, this is not ill-formed. Just UB.
>
>
> yes, this is what I wanted to say.
>
> Vicente
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">So as you can see, people in this discussion looking at th=
e Qt expression are confused as to whether its behavior is undefined or uns=
pecified.=C2=A0 Which has always been my point.=C2=A0 Presumably people par=
ticipating in this discussion are experts (at least to some extent), and ye=
t even they get this sort of thing wrong.<br><br>&quot;Frank HB&quot;, who =
argued that &quot;<span style=3D"font-size:12.8px">a programmer who don&#39=
;t have enough common sense about sequence rules (also imply the definition=
 of &quot;undefined behavior&quot;), should not be granted permission of mo=
dify the C++ code base in a serious project&quot; must presumably now inclu=
de himself in his ban, since he replied to &quot;</span><span style=3D"colo=
r:rgb(80,0,80);font-size:12.8px">If any of the subexpression evaluation can=
 change the value of m_coursor, the expression evaluation can not be done o=
n any order and so UB.&quot; with &quot;</span><span style=3D"font-size:12.=
8px">Yes. (Even there is only one modification to the stored value.)</span>=
<span style=3D"font-size:12.8px">=C2=A0&quot;<br></span><blockquote type=3D=
"cite" style=3D"color:rgb(80,0,80);font-size:12.8px"><div dir=3D"ltr"></div=
></blockquote><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Thu, Dec 10, 2015 at 5:26 PM, Vicente J. Botet Escriba <span dir=3D"ltr">&l=
t;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bot=
et@wanadoo.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF"><div><div class=3D"h5">
    <div>Le 10/12/2015 02:37, FrankHB1989 a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"><br>
      <br>
      =E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=
=9B UTC+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=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 text=3D"#000000" bgcolor=3D"#FFFFFF">
          <div>Le 09/12/2015 22:08, Myriachan a =C3=A9crit=C2=A0:<br>
          </div>
          <blockquote type=3D"cite">On Wednesday, December 9, 2015 at
            7:37:37 AM UTC-8, Matthew Woehlke wrote:
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-12-09 09:40, &#=
39;Edward
              Catmur&#39; wrote: <br>
              &gt; On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote: <br>
              &gt;&gt; Show us. Make a case with genuine evidence. In a
              project the size of Qt, <br>
              &gt;&gt; for example, how many cases are there where CSE
              could be employed now but <br>
              &gt;&gt; not under the new rules? <br>
              &gt; <br>
              &gt; OK, here&#39;s one in Qt, found just by browsing recent
              commits: <br>
              &gt; <a href=3D"https://github.com/qtproject/qtbase/blob/f37e=
a6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol=
..cpp#L243" rel=3D"nofollow" target=3D"_blank">https://github.com/qtproject/=
qtbase/blob/f37ea6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qw=
idgetlinecontrol.cpp#L243</a>
              <br>
              &gt; <br>
              &gt; int n =3D textLayout()-&gt;nextCursorPosition(m_cursor)

              - m_cursor; <br>
              &gt; Currently, the loads from m_cursor can be collapsed;
              in the presence of <br>
              &gt; fixed evaluation order the LHS subexpression could
              change the value of <br>
              &gt; m_cursor so it has to be reloaded. <br>
              <br>
              I wonder if this example works...? On the one hand,
              textLayout() is a <br>
              const method, so cannot change m_cursor. On the other, it
              returns a <br>
              mutable object of another type, whose methods may not be
              inline, and I <br>
              doubt the compiler can statically prove that methods
              called on the other <br>
              object can&#39;t modify (in this example) m_cursor. (Certainl=
y
              I could <br>
              readily contrive a pathological example that does exactly
              that in a way <br>
              that the compiler can&#39;t detect.) <br>
              <br>
              So... ah, yeah. Ick. I *was* ambivalent as to this
              proposal, until that <br>
              example. Now I&#39;m not thrilled with it myself... <br>
              <br>
            </blockquote>
            <div><br>
              If the evaluation order were only guaranteed for certain
              operators, - would likely not be one of them.<br>
              <br>
              <span style=3D"color:rgb(167,29,93)">int</span> n =3D <span s=
tyle=3D"color:rgb(0,134,179)">textLayout</span>()-&gt;<span style=3D"color:=
rgb(0,134,179)">nextCursorPosition</span>(m_cursor)

              - m_cursor;<br>
              <br>
              In this case, the sequenced-before guarantees would be
              that the textLayout() function call occurs before
              SomeLayoutType::nextCursorPosition().=C2=A0 The reading of
              m_cursor, either for the function parameter or the
              subtrahend, would be unsequenced relative to the others.<br>
            </div>
            <br>
          </blockquote>
          Yes this example is troubling. It is natural to think that the
          value of m_cursor for the two leaves would be the same. But a
          sequential evaluation could result on different values for
          m_cursor on the same expression :(<br>
          <br>
          I don&#39;t know, while the new rule will make more programs
          correct as some UB is eliminated, the semantics doesn&#39;t match
          with the mental model.<br>
          <br>
        </div>
      </blockquote>
      <div>I believe it would be worse, whether the original code is
        buggy or not. This is one reason that I am against the change.<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 text=3D"#000000" bgcolor=3D"#FFFFFF"> So maybe we should stay
          with the current rule and ler the program be ill-formed.<br>
          <br>
        </div>
      </blockquote>
      <div>As said, this is not ill-formed. Just UB.<br>
        =C2=A0<br>
      </div>
      <br>
    </blockquote></div></div>
    yes, this is what I wanted to say. <br><span class=3D"HOEnZb"><font col=
or=3D"#888888">
    <br>
    Vicente<br>
  </font></span></div><div class=3D"HOEnZb"><div class=3D"h5">


<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11440dfa70c5660526a34f08--

.

------=_Part_2864_762222933.1449892867645
Content-Type: multipart/alternative;
 boundary="----=_Part_2865_258539066.1449892867645"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UT=
C+8=E4=B8=8A=E5=8D=882:15:40=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> So as you can see, people in this discussion looking at the Qt expression=
=20
> are confused as to whether its behavior is undefined or unspecified.  Whi=
ch=20
> has always been my point.  Presumably people participating in this=20
> discussion are experts (at least to some extent), and yet even they get=
=20
> this sort of thing wrong.
>
> "Frank HB", who argued that "a programmer who don't have enough common=20
> sense about sequence rules (also imply the definition of "undefined=20
> behavior"), should not be granted permission of modify the C++ code base =
in=20
> a serious project" must presumably now include himself in his ban, since =
he=20
> replied to "If any of the subexpression evaluation can change the value=
=20
> of m_coursor, the expression evaluation can not be done on any order and =
so=20
> UB." with "Yes. (Even there is only one modification to the stored value.=
)
>  "
>
>
> On Thu, Dec 10, 2015 at 5:26 PM, Vicente J. Botet Escriba <
> vicent...@wanadoo.fr <javascript:>> wrote:
>
>> Le 10/12/2015 02:37, FrankHB1989 a =C3=A9crit :
>>
>>
>>
>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B=
 UTC+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=E5=86=99=
=E9=81=93=EF=BC=9A=20
>>>
>>> Le 09/12/2015 22:08, Myriachan a =C3=A9crit :
>>>
>>> On Wednesday, December 9, 2015 at 7:37:37 AM UTC-8, Matthew Woehlke=20
>>> wrote:=20
>>>>
>>>> On 2015-12-09 09:40, 'Edward Catmur' wrote:=20
>>>> > On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:=20
>>>> >> Show us. Make a case with genuine evidence. In a project the size o=
f=20
>>>> Qt,=20
>>>> >> for example, how many cases are there where CSE could be employed=
=20
>>>> now but=20
>>>> >> not under the new rules?=20
>>>> >=20
>>>> > OK, here's one in Qt, found just by browsing recent commits:=20
>>>> >=20
>>>> https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7ad=
42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243=20
>>>> >=20
>>>> > int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;=20
>>>> > Currently, the loads from m_cursor can be collapsed; in the presence=
=20
>>>> of=20
>>>> > fixed evaluation order the LHS subexpression could change the value=
=20
>>>> of=20
>>>> > m_cursor so it has to be reloaded.=20
>>>>
>>>> I wonder if this example works...? On the one hand, textLayout() is a=
=20
>>>> const method, so cannot change m_cursor. On the other, it returns a=20
>>>> mutable object of another type, whose methods may not be inline, and I=
=20
>>>> doubt the compiler can statically prove that methods called on the=20
>>>> other=20
>>>> object can't modify (in this example) m_cursor. (Certainly I could=20
>>>> readily contrive a pathological example that does exactly that in a wa=
y=20
>>>> that the compiler can't detect.)=20
>>>>
>>>> So... ah, yeah. Ick. I *was* ambivalent as to this proposal, until tha=
t=20
>>>> example. Now I'm not thrilled with it myself...=20
>>>>
>>>>
>>> If the evaluation order were only guaranteed for certain operators, -=
=20
>>> would likely not be one of them.
>>>
>>> int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>>>
>>> In this case, the sequenced-before guarantees would be that the=20
>>> textLayout() function call occurs before=20
>>> SomeLayoutType::nextCursorPosition().  The reading of m_cursor, either =
for=20
>>> the function parameter or the subtrahend, would be unsequenced relative=
 to=20
>>> the others.
>>>
>>> Yes this example is troubling. It is natural to think that the value of=
=20
>>> m_cursor for the two leaves would be the same. But a sequential evaluat=
ion=20
>>> could result on different values for m_cursor on the same expression :(
>>>
>>> I don't know, while the new rule will make more programs correct as som=
e=20
>>> UB is eliminated, the semantics doesn't match with the mental model.
>>>
>>> I believe it would be worse, whether the original code is buggy or not.=
=20
>> This is one reason that I am against the change.
>> =20
>>
>>> So maybe we should stay with the current rule and ler the program be=20
>>> ill-formed.
>>>
>>> As said, this is not ill-formed. Just UB.
>> =20
>>
>> yes, this is what I wanted to say.=20
>>
>> Vicente
>>
>> --=20
>>
>> ---=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:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> OK, you win. This was only right as the immediately reply to "the=20
expression evaluation can not be done on any order and so UB".=20

I did not see the original code and the context carefully, so missed "can c=
hange=20
the value of m_cursor" is specific within the function invocation.

The only subexpression remained to take into account here is m_cursor=20
itself, which could be UB when

volatile int m_cursor =3D 42;

It is UB whether the value of m_cursor can be changed or not (not the=20
original code, again). However, not by "change the value of m_cursor".

Sorry for my careless and misleading answer.

And I'm glad you'd agree the indeterminate rules on function invocation=20
should also be part of common sense, which is far more aggressive than my=
=20
previous point:) I had little interest in this rule because it is still too=
=20
specific and makes builtin/overloaded operators behave differently. I=20
previously think that [intro.execution]/15 is not the necessary evil=20
everyone should care because relying on it would reduce the readability in=
=20
general, and produce such bad confusion even I am easy to miss. (But=20
[intro.execution]/13 is).



--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=85=AD UTC+8=E4=B8=8A=E5=8D=882:15: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 dir=3D"ltr">So a=
s you can see, people in this discussion looking at the Qt expression are c=
onfused as to whether its behavior is undefined or unspecified.=C2=A0 Which=
 has always been my point.=C2=A0 Presumably people participating in this di=
scussion are experts (at least to some extent), and yet even they get this =
sort of thing wrong.<br><br>&quot;Frank HB&quot;, who argued that &quot;<sp=
an style=3D"font-size:12.8px">a programmer who don&#39;t have enough common=
 sense about sequence rules (also imply the definition of &quot;undefined b=
ehavior&quot;), should not be granted permission of modify the C++ code bas=
e in a serious project&quot; must presumably now include himself in his ban=
, since he replied to &quot;</span><span style=3D"color:rgb(80,0,80);font-s=
ize:12.8px">If any of the subexpression evaluation can change the value of =
m_coursor, the expression evaluation can not be done on any order and so UB=
..&quot; with &quot;</span><span style=3D"font-size:12.8px">Yes. (Even there=
 is only one modification to the stored value.)</span><span style=3D"font-s=
ize:12.8px">=C2=A0&quot;<br></span><blockquote type=3D"cite" style=3D"color=
:rgb(80,0,80);font-size:12.8px"><div dir=3D"ltr"></div></blockquote><div><b=
r><div class=3D"gmail_quote">On Thu, Dec 10, 2015 at 5:26 PM, Vicente J. Bo=
tet Escriba <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"7fPhEPa_CwAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">vicent...@wanadoo.fr</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF"><div><div>
    <div>Le 10/12/2015 02:37, FrankHB1989 a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"><br>
      <br>
      =E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=
=9B UTC+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=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 text=3D"#000000" bgcolor=3D"#FFFFFF">
          <div>Le 09/12/2015 22:08, Myriachan a =C3=A9crit=C2=A0:<br>
          </div>
          <blockquote type=3D"cite">On Wednesday, December 9, 2015 at
            7:37:37 AM UTC-8, Matthew Woehlke wrote:
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-12-09 09:40, &#=
39;Edward
              Catmur&#39; wrote: <br>
              &gt; On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote: <br>
              &gt;&gt; Show us. Make a case with genuine evidence. In a
              project the size of Qt, <br>
              &gt;&gt; for example, how many cases are there where CSE
              could be employed now but <br>
              &gt;&gt; not under the new rules? <br>
              &gt; <br>
              &gt; OK, here&#39;s one in Qt, found just by browsing recent
              commits: <br>
              &gt; <a href=3D"https://github.com/qtproject/qtbase/blob/f37e=
a6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol=
..cpp#L243" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#=
39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fqtproject%2Fqt=
base%2Fblob%2Ff37ea6c5c61099851d9df57c8d7ad42150b0bc03%2Fsrc%2Fwidgets%2Fwi=
dgets%2Fqwidgetlinecontrol.cpp%23L243\46sa\75D\46sntz\0751\46usg\75AFQjCNFo=
Yl-9DbQgccgNskoL2PH5Oj4Xkg&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fqtproject%2Fqtbase=
%2Fblob%2Ff37ea6c5c61099851d9df57c8d7ad42150b0bc03%2Fsrc%2Fwidgets%2Fwidget=
s%2Fqwidgetlinecontrol.cpp%23L243\46sa\75D\46sntz\0751\46usg\75AFQjCNFoYl-9=
DbQgccgNskoL2PH5Oj4Xkg&#39;;return true;">https://github.com/qtproject/<wbr=
>qtbase/blob/<wbr>f37ea6c5c61099851d9df57c8d7ad4<wbr>2150b0bc03/src/widgets=
/<wbr>widgets/qwidgetlinecontrol.<wbr>cpp#L243</a>
              <br>
              &gt; <br>
              &gt; int n =3D textLayout()-&gt;<wbr>nextCursorPosition(m_cur=
sor)

              - m_cursor; <br>
              &gt; Currently, the loads from m_cursor can be collapsed;
              in the presence of <br>
              &gt; fixed evaluation order the LHS subexpression could
              change the value of <br>
              &gt; m_cursor so it has to be reloaded. <br>
              <br>
              I wonder if this example works...? On the one hand,
              textLayout() is a <br>
              const method, so cannot change m_cursor. On the other, it
              returns a <br>
              mutable object of another type, whose methods may not be
              inline, and I <br>
              doubt the compiler can statically prove that methods
              called on the other <br>
              object can&#39;t modify (in this example) m_cursor. (Certainl=
y
              I could <br>
              readily contrive a pathological example that does exactly
              that in a way <br>
              that the compiler can&#39;t detect.) <br>
              <br>
              So... ah, yeah. Ick. I *was* ambivalent as to this
              proposal, until that <br>
              example. Now I&#39;m not thrilled with it myself... <br>
              <br>
            </blockquote>
            <div><br>
              If the evaluation order were only guaranteed for certain
              operators, - would likely not be one of them.<br>
              <br>
              <span style=3D"color:rgb(167,29,93)">int</span> n =3D <span s=
tyle=3D"color:rgb(0,134,179)">textLayout</span>()-&gt;<span style=3D"color:=
rgb(0,134,179)">nextCursorPositi<wbr>on</span>(m_cursor)

              - m_cursor;<br>
              <br>
              In this case, the sequenced-before guarantees would be
              that the textLayout() function call occurs before
              SomeLayoutType::<wbr>nextCursorPosition().=C2=A0 The reading =
of
              m_cursor, either for the function parameter or the
              subtrahend, would be unsequenced relative to the others.<br>
            </div>
            <br>
          </blockquote>
          Yes this example is troubling. It is natural to think that the
          value of m_cursor for the two leaves would be the same. But a
          sequential evaluation could result on different values for
          m_cursor on the same expression :(<br>
          <br>
          I don&#39;t know, while the new rule will make more programs
          correct as some UB is eliminated, the semantics doesn&#39;t match
          with the mental model.<br>
          <br>
        </div>
      </blockquote>
      <div>I believe it would be worse, whether the original code is
        buggy or not. This is one reason that I am against the change.<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 text=3D"#000000" bgcolor=3D"#FFFFFF"> So maybe we should stay
          with the current rule and ler the program be ill-formed.<br>
          <br>
        </div>
      </blockquote>
      <div>As said, this is not ill-formed. Just UB.<br>
        =C2=A0<br>
      </div>
      <br>
    </blockquote></div></div>
    yes, this is what I wanted to say. <br><span><font color=3D"#888888">
    <br>
    Vicente<br>
  </font></span></div><div><div>


<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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"=
7fPhEPa_CwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;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"7fPhEPa_CwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></blockquote><div>OK, you wi=
n. This was only right as the immediately reply to &quot;<span>the expressi=
on evaluation can not be done on any order
    and so UB</span>&quot;. <br><br>I did not see the original code and the=
 context carefully, so missed &quot;can <span>change the value of
    m_cursor</span>&quot; is specific within the function invocation.<br><b=
r>The only subexpression remained to take into account here is m_cursor its=
elf, which could be UB when<br><br><span style=3D"color:rgb(167,29,93)">vol=
atile int</span> m_cursor =3D 42;<br><span style=3D"color:rgb(167,29,93)"><=
/span><br> It is UB whether the value of m_cursor can be changed or not (no=
t the original code, again). However, not by &quot;<span>change the value o=
f
    m_cursor</span>&quot;.<br><br>Sorry for my careless and misleading answ=
er.<br><br>And I&#39;m glad you&#39;d agree the indeterminate rules on func=
tion invocation should also be part of common sense, which is far more aggr=
essive than my previous point:) I had little interest in this rule because =
it is still too specific and makes builtin/overloaded operators behave diff=
erently. I previously think that [intro.execution]/15 is not the necessary =
evil everyone should care because relying on it would reduce the readabilit=
y in general, and produce such bad confusion even I am easy to miss. (But [=
intro.execution]/13 is).<br><br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_2865_258539066.1449892867645--
------=_Part_2864_762222933.1449892867645--

.

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

Well, no.  I believe that there should be no indeterminate rules on
function invocation; like other expressions, evaluation should be strictly
left-to-right, so that in

textLayout()->nextCursorPosition(m_cursor) - m_cursor;

the first evaluation of m_cursor happens after textLayout() returns and the
second happens after nextCursorPosition() returns.  The only common sense
required is the realization that it's common sense to require strict
left-to-right order of evaluation, because even if that rule is surprising
on first hearing, it's never surprising again.

On Fri, Dec 11, 2015 at 11:01 PM, FrankHB1989 <frankhb1989@gmail.com> wrote=
:

>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD =
UTC+8=E4=B8=8A=E5=8D=882:15:40=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> So as you can see, people in this discussion looking at the Qt expressio=
n
>> are confused as to whether its behavior is undefined or unspecified.  Wh=
ich
>> has always been my point.  Presumably people participating in this
>> discussion are experts (at least to some extent), and yet even they get
>> this sort of thing wrong.
>>
>> "Frank HB", who argued that "a programmer who don't have enough common
>> sense about sequence rules (also imply the definition of "undefined
>> behavior"), should not be granted permission of modify the C++ code base=
 in
>> a serious project" must presumably now include himself in his ban, since=
 he
>> replied to "If any of the subexpression evaluation can change the value
>> of m_coursor, the expression evaluation can not be done on any order and=
 so
>> UB." with "Yes. (Even there is only one modification to the stored
>> value.) "
>>
>>
>> On Thu, Dec 10, 2015 at 5:26 PM, Vicente J. Botet Escriba <
>> vicent...@wanadoo.fr> wrote:
>>
>>> Le 10/12/2015 02:37, FrankHB1989 a =C3=A9crit :
>>>
>>>
>>>
>>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=
=9B UTC+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=E5=86=
=99=E9=81=93=EF=BC=9A
>>>>
>>>> Le 09/12/2015 22:08, Myriachan a =C3=A9crit :
>>>>
>>>> On Wednesday, December 9, 2015 at 7:37:37 AM UTC-8, Matthew Woehlke
>>>> wrote:
>>>>>
>>>>> On 2015-12-09 09:40, 'Edward Catmur' wrote:
>>>>> > On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote:
>>>>> >> Show us. Make a case with genuine evidence. In a project the size
>>>>> of Qt,
>>>>> >> for example, how many cases are there where CSE could be employed
>>>>> now but
>>>>> >> not under the new rules?
>>>>> >
>>>>> > OK, here's one in Qt, found just by browsing recent commits:
>>>>> >
>>>>> https://github.com/qtproject/qtbase/blob/f37ea6c5c61099851d9df57c8d7a=
d42150b0bc03/src/widgets/widgets/qwidgetlinecontrol.cpp#L243
>>>>> >
>>>>> > int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>>>>> > Currently, the loads from m_cursor can be collapsed; in the presenc=
e
>>>>> of
>>>>> > fixed evaluation order the LHS subexpression could change the value
>>>>> of
>>>>> > m_cursor so it has to be reloaded.
>>>>>
>>>>> I wonder if this example works...? On the one hand, textLayout() is a
>>>>> const method, so cannot change m_cursor. On the other, it returns a
>>>>> mutable object of another type, whose methods may not be inline, and =
I
>>>>> doubt the compiler can statically prove that methods called on the
>>>>> other
>>>>> object can't modify (in this example) m_cursor. (Certainly I could
>>>>> readily contrive a pathological example that does exactly that in a
>>>>> way
>>>>> that the compiler can't detect.)
>>>>>
>>>>> So... ah, yeah. Ick. I *was* ambivalent as to this proposal, until
>>>>> that
>>>>> example. Now I'm not thrilled with it myself...
>>>>>
>>>>>
>>>> If the evaluation order were only guaranteed for certain operators, -
>>>> would likely not be one of them.
>>>>
>>>> int n =3D textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>>>>
>>>> In this case, the sequenced-before guarantees would be that the
>>>> textLayout() function call occurs before
>>>> SomeLayoutType::nextCursorPosition().  The reading of m_cursor, either=
 for
>>>> the function parameter or the subtrahend, would be unsequenced relativ=
e to
>>>> the others.
>>>>
>>>> Yes this example is troubling. It is natural to think that the value o=
f
>>>> m_cursor for the two leaves would be the same. But a sequential evalua=
tion
>>>> could result on different values for m_cursor on the same expression :=
(
>>>>
>>>> I don't know, while the new rule will make more programs correct as
>>>> some UB is eliminated, the semantics doesn't match with the mental mod=
el.
>>>>
>>>> I believe it would be worse, whether the original code is buggy or not=
..
>>> This is one reason that I am against the change.
>>>
>>>
>>>> So maybe we should stay with the current rule and ler the program be
>>>> ill-formed.
>>>>
>>>> As said, this is not ill-formed. Just UB.
>>>
>>>
>>> yes, this is what I wanted to say.
>>>
>>> Vicente
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are 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.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> OK, you win. This was only right as the immediately reply to "the
> expression evaluation can not be done on any order and so UB".
>
> I did not see the original code and the context carefully, so missed "can=
 change
> the value of m_cursor" is specific within the function invocation.
>
> The only subexpression remained to take into account here is m_cursor
> itself, which could be UB when
>
> volatile int m_cursor =3D 42;
>
> It is UB whether the value of m_cursor can be changed or not (not the
> original code, again). However, not by "change the value of m_cursor".
>
> Sorry for my careless and misleading answer.
>
> And I'm glad you'd agree the indeterminate rules on function invocation
> should also be part of common sense, which is far more aggressive than my
> previous point:) I had little interest in this rule because it is still t=
oo
> specific and makes builtin/overloaded operators behave differently. I
> previously think that [intro.execution]/15 is not the necessary evil
> everyone should care because relying on it would reduce the readability i=
n
> general, and produce such bad confusion even I am easy to miss. (But
> [intro.execution]/13 is).
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">Well, no.=C2=A0 I believe that there should be no indeterm=
inate rules on function invocation; like other expressions, evaluation shou=
ld be strictly left-to-right, so that in=C2=A0<br><blockquote type=3D"cite"=
 style=3D"color:rgb(80,0,80);font-size:12.8px"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><table><tbody><tr><td style=3D"font-family:Consolas,&#39;L=
iberation Mono&#39;,Menlo,Courier,monospace;padding:0px 10px;vertical-align=
:top;font-size:12px;white-space:pre-wrap;overflow:visible;word-wrap:normal;=
background-color:rgb(248,238,199)"><span style=3D"color:rgb(0,134,179)">tex=
tLayout</span>()-&gt;<span style=3D"color:rgb(0,134,179)">nextCursorPositio=
n</span>(m_cursor) - m_cursor;</td></tr></tbody></table></div></div></block=
quote><span style=3D"font-size:12.8px"><font color=3D"#000000">the first ev=
aluation of m_cursor happens after textLayout() returns and the second happ=
ens after nextCursorPosition() returns.=C2=A0 The only common sense require=
d is the realization that it&#39;s common sense to require strict left-to-r=
ight order of evaluation, because even if that rule is surprising on first =
hearing, it&#39;s never surprising again.</font></span></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Fri, Dec 11, 2015 at 11:01 P=
M, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.co=
m" target=3D"_blank">frankhb1989@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8812=E6=97=
=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=882:15: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"><d=
iv dir=3D"ltr"><span class=3D"">So as you can see, people in this discussio=
n looking at the Qt expression are confused as to whether its behavior is u=
ndefined or unspecified.=C2=A0 Which has always been my point.=C2=A0 Presum=
ably people participating in this discussion are experts (at least to some =
extent), and yet even they get this sort of thing wrong.<br><br>&quot;Frank=
 HB&quot;, who argued that &quot;<span style=3D"font-size:12.8px">a program=
mer who don&#39;t have enough common sense about sequence rules (also imply=
 the definition of &quot;undefined behavior&quot;), should not be granted p=
ermission of modify the C++ code base in a serious project&quot; must presu=
mably now include himself in his ban, since he replied to &quot;</span><spa=
n style=3D"color:rgb(80,0,80);font-size:12.8px">If any of the subexpression=
 evaluation can change the value of m_coursor, the expression evaluation ca=
n not be done on any order and so UB.&quot; with &quot;</span><span style=
=3D"font-size:12.8px">Yes. (Even there is only one modification to the stor=
ed value.)</span><span style=3D"font-size:12.8px">=C2=A0&quot;<br></span><b=
lockquote type=3D"cite" style=3D"color:rgb(80,0,80);font-size:12.8px"><div =
dir=3D"ltr"></div></blockquote></span><div><br><div class=3D"gmail_quote"><=
div><div class=3D"h5">On Thu, Dec 10, 2015 at 5:26 PM, Vicente J. Botet Esc=
riba <span dir=3D"ltr">&lt;<a rel=3D"nofollow">vicent...@wanadoo.fr</a>&gt;=
</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div clas=
s=3D"h5">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF"><div><div>
    <div>Le 10/12/2015 02:37, FrankHB1989 a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"><br>
      <br>
      =E5=9C=A8 2015=E5=B9=B412=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=
=9B UTC+8=E4=B8=8A=E5=8D=886:33:00=EF=BC=8CVicente J. Botet Escriba=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 text=3D"#000000" bgcolor=3D"#FFFFFF">
          <div>Le 09/12/2015 22:08, Myriachan a =C3=A9crit=C2=A0:<br>
          </div>
          <blockquote type=3D"cite">On Wednesday, December 9, 2015 at
            7:37:37 AM UTC-8, Matthew Woehlke wrote:
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-12-09 09:40, &#=
39;Edward
              Catmur&#39; wrote: <br>
              &gt; On Tue, Dec 8, 2015 at 2:06 PM, Nicol Bolas wrote: <br>
              &gt;&gt; Show us. Make a case with genuine evidence. In a
              project the size of Qt, <br>
              &gt;&gt; for example, how many cases are there where CSE
              could be employed now but <br>
              &gt;&gt; not under the new rules? <br>
              &gt; <br>
              &gt; OK, here&#39;s one in Qt, found just by browsing recent
              commits: <br>
              &gt; <a href=3D"https://github.com/qtproject/qtbase/blob/f37e=
a6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qwidgetlinecontrol=
..cpp#L243" rel=3D"nofollow" target=3D"_blank">https://github.com/qtproject/=
qtbase/blob/f37ea6c5c61099851d9df57c8d7ad42150b0bc03/src/widgets/widgets/qw=
idgetlinecontrol.cpp#L243</a>
              <br>
              &gt; <br>
              &gt; int n =3D textLayout()-&gt;nextCursorPosition(m_cursor)

              - m_cursor; <br>
              &gt; Currently, the loads from m_cursor can be collapsed;
              in the presence of <br>
              &gt; fixed evaluation order the LHS subexpression could
              change the value of <br>
              &gt; m_cursor so it has to be reloaded. <br>
              <br>
              I wonder if this example works...? On the one hand,
              textLayout() is a <br>
              const method, so cannot change m_cursor. On the other, it
              returns a <br>
              mutable object of another type, whose methods may not be
              inline, and I <br>
              doubt the compiler can statically prove that methods
              called on the other <br>
              object can&#39;t modify (in this example) m_cursor. (Certainl=
y
              I could <br>
              readily contrive a pathological example that does exactly
              that in a way <br>
              that the compiler can&#39;t detect.) <br>
              <br>
              So... ah, yeah. Ick. I *was* ambivalent as to this
              proposal, until that <br>
              example. Now I&#39;m not thrilled with it myself... <br>
              <br>
            </blockquote>
            <div><br>
              If the evaluation order were only guaranteed for certain
              operators, - would likely not be one of them.<br>
              <br>
              <span style=3D"color:rgb(167,29,93)">int</span> n =3D <span s=
tyle=3D"color:rgb(0,134,179)">textLayout</span>()-&gt;<span style=3D"color:=
rgb(0,134,179)">nextCursorPosition</span>(m_cursor)

              - m_cursor;<br>
              <br>
              In this case, the sequenced-before guarantees would be
              that the textLayout() function call occurs before
              SomeLayoutType::nextCursorPosition().=C2=A0 The reading of
              m_cursor, either for the function parameter or the
              subtrahend, would be unsequenced relative to the others.<br>
            </div>
            <br>
          </blockquote>
          Yes this example is troubling. It is natural to think that the
          value of m_cursor for the two leaves would be the same. But a
          sequential evaluation could result on different values for
          m_cursor on the same expression :(<br>
          <br>
          I don&#39;t know, while the new rule will make more programs
          correct as some UB is eliminated, the semantics doesn&#39;t match
          with the mental model.<br>
          <br>
        </div>
      </blockquote>
      <div>I believe it would be worse, whether the original code is
        buggy or not. This is one reason that I am against the change.<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 text=3D"#000000" bgcolor=3D"#FFFFFF"> So maybe we should stay
          with the current rule and ler the program be ill-formed.<br>
          <br>
        </div>
      </blockquote>
      <div>As said, this is not ill-formed. Just UB.<br>
        =C2=A0<br>
      </div>
      <br>
    </blockquote></div></div>
    yes, this is what I wanted to say. <br><span><font color=3D"#888888">
    <br>
    Vicente<br>
  </font></span></div></div></div><div><div><div><div class=3D"h5">


<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
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>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div></div></blockquote><div>OK,=
 you win. This was only right as the immediately reply to &quot;<span>the e=
xpression evaluation can not be done on any order
    and so UB</span>&quot;. <br><br>I did not see the original code and the=
 context carefully, so missed &quot;can <span>change the value of
    m_cursor</span>&quot; is specific within the function invocation.<br><b=
r>The only subexpression remained to take into account here is m_cursor its=
elf, which could be UB when<br><br><span style=3D"color:rgb(167,29,93)">vol=
atile int</span> m_cursor =3D 42;<br><span style=3D"color:rgb(167,29,93)"><=
/span><br> It is UB whether the value of m_cursor can be changed or not (no=
t the original code, again). However, not by &quot;<span>change the value o=
f
    m_cursor</span>&quot;.<br><br>Sorry for my careless and misleading answ=
er.<br><br>And I&#39;m glad you&#39;d agree the indeterminate rules on func=
tion invocation should also be part of common sense, which is far more aggr=
essive than my previous point:) I had little interest in this rule because =
it is still too specific and makes builtin/overloaded operators behave diff=
erently. I previously think that [intro.execution]/15 is not the necessary =
evil everyone should care because relying on it would reduce the readabilit=
y in general, and produce such bad confusion even I am easy to miss. (But [=
intro.execution]/13 is).<br><br><br><br></div><span class=3D"">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a114401763832df0526dded0e--

.

------=_Part_5683_900594843.1450150200235
Content-Type: multipart/alternative;
 boundary="----=_Part_5684_2064605550.1450150200243"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UT=
C+8=E4=B8=8A=E5=8D=8812:11:37=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>
> Well, no.  I believe that there should be no indeterminate rules on=20
> function invocation; like other expressions, evaluation should be strictl=
y=20
> left-to-right, so that in=20
>
> textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>
> the first evaluation of m_cursor happens after textLayout() returns and=
=20
> the second happens after nextCursorPosition() returns.  The only common=
=20
> sense required is the realization that it's common sense to require stric=
t=20
> left-to-right order of evaluation, because even if that rule is surprisin=
g=20
> on first hearing, it's never surprising again.
>
>
> =20
Why need it to be common sense? I'm surprising this kind of rules should be=
=20
inferred from elsewhere.
=20
Well, even if learning with help of experience ... it should be knowledge=
=20
of programming languages, not natural languages. They are too different.=20
Then:

   - The rules are nonsense to one who did not even know what is=20
   "evaluation", which is more or less similar in any practical programming=
=20
   languages.
   - Not all of them use the same "left-to-right" rules, i.e.=20
   "left-to-right" is significantly restrictive and less "common" in this=
=20
   sense.
   - So unless for some specific languages, "left-to-right" is happened to=
=20
   be, not expected to be.
  =20
Keeping "left-to-right" common is not safe for people who need to work with=
=20
multiple languages. For these users and beginners, keeping "unspecific" in=
=20
mind is sane and safer. (Or you will propose to change every programming=20
languages you see?)


And again, I see nothing that relying on the not-so-common rules would=20
benefit. (If any ... tolerance on buggy code?)



=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=8C UTC+8=E4=B8=8A=E5=8D=8812:11:37=EF=BC=8CHyman Rosen=E5=86=99=E9=81=
=93=EF=BC=9A<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">W=
ell, no.=C2=A0 I believe that there should be no indeterminate rules on fun=
ction invocation; like other expressions, evaluation should be strictly lef=
t-to-right, so that in=C2=A0<br><blockquote type=3D"cite" style=3D"color:rg=
b(80,0,80);font-size:12.8px"><div dir=3D"ltr"><div class=3D"gmail_quote"><t=
able><tbody><tr><td style=3D"font-family:Consolas,&#39;Liberation Mono&#39;=
,Menlo,Courier,monospace;padding:0px 10px;vertical-align:top;font-size:12px=
;white-space:pre-wrap;overflow:visible;word-wrap:normal;background-color:rg=
b(248,238,199)"><span style=3D"color:rgb(0,134,179)">textLayout</span>()-&g=
t;<span style=3D"color:rgb(0,134,179)">nextCursorPositi<wbr>on</span>(m_cur=
sor) - m_cursor;</td></tr></tbody></table></div></div></blockquote><span st=
yle=3D"font-size:12.8px"><font color=3D"#000000">the first evaluation of m_=
cursor happens after textLayout() returns and the second happens after next=
CursorPosition() returns.=C2=A0 The only common sense required is the reali=
zation that it&#39;s common sense to require strict left-to-right order of =
evaluation, because even if that rule is surprising on first hearing, it&#3=
9;s never surprising again.</font></span></div><div><br><br></div></blockqu=
ote><div>=C2=A0</div><div>Why need it to be common sense? I&#39;m surprisin=
g this kind of rules should be inferred from elsewhere.<br>=C2=A0<br></div>=
<div>Well, even if learning with help of experience ... it should be knowle=
dge of programming languages, not natural languages. They are too different=
.. Then:<br><ul><li>The rules are nonsense to one who did not even know what=
 is &quot;evaluation&quot;, which is more or less similar in any practical =
programming languages.</li><li>Not all of them use the same &quot;left-to-r=
ight&quot; rules, i.e. &quot;left-to-right&quot; is significantly restricti=
ve and less &quot;common&quot; in this sense.</li><li>So unless for some sp=
ecific languages, &quot;left-to-right&quot; is happened to be, not expected=
 to be.<br></li></ul><p>Keeping &quot;left-to-right&quot; common is not saf=
e for people who need to work with multiple languages. For these users and =
beginners, keeping &quot;unspecific&quot; in mind is sane and safer. (Or yo=
u will propose to change every programming languages you see?)</p><p><br></=
p><p>And again, I see nothing that relying on the not-so-common rules would=
 benefit. (If any ... tolerance on buggy code?)</p><p><br></p><p><br></p>=
=C2=A0<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_5684_2064605550.1450150200243--
------=_Part_5683_900594843.1450150200235--

.

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

The language rules for C++ are for C++ (and maybe C).  Requiring that C++
must have built-in stupidity to match the built-in stupidity that people
have learned in other languages leads to an insane downward spiral where
nothing can be made better because people only know worse.  That is not a
theory I accept.

On Mon, Dec 14, 2015 at 10:30 PM, FrankHB1989 <frankhb1989@gmail.com> wrote=
:

>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C =
UTC+8=E4=B8=8A=E5=8D=8812:11:37=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> Well, no.  I believe that there should be no indeterminate rules on
>> function invocation; like other expressions, evaluation should be strict=
ly
>> left-to-right, so that in
>>
>> textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>>
>> the first evaluation of m_cursor happens after textLayout() returns and
>> the second happens after nextCursorPosition() returns.  The only common
>> sense required is the realization that it's common sense to require stri=
ct
>> left-to-right order of evaluation, because even if that rule is surprisi=
ng
>> on first hearing, it's never surprising again.
>>
>>
>>
> Why need it to be common sense? I'm surprising this kind of rules should
> be inferred from elsewhere.
>
> Well, even if learning with help of experience ... it should be knowledge
> of programming languages, not natural languages. They are too different.
> Then:
>
>    - The rules are nonsense to one who did not even know what is
>    "evaluation", which is more or less similar in any practical programmi=
ng
>    languages.
>    - Not all of them use the same "left-to-right" rules, i.e.
>    "left-to-right" is significantly restrictive and less "common" in this
>    sense.
>    - So unless for some specific languages, "left-to-right" is happened
>    to be, not expected to be.
>
> Keeping "left-to-right" common is not safe for people who need to work
> with multiple languages. For these users and beginners, keeping
> "unspecific" in mind is sane and safer. (Or you will propose to change
> every programming languages you see?)
>
>
> And again, I see nothing that relying on the not-so-common rules would
> benefit. (If any ... tolerance on buggy 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.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">The language rules for C++ are for C++ (and maybe C).=C2=
=A0 Requiring that C++ must have built-in stupidity to match the built-in s=
tupidity that people have learned in other languages leads to an insane dow=
nward spiral where nothing can be made better because people only know wors=
e.=C2=A0 That is not a theory I accept.</div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Mon, Dec 14, 2015 at 10:30 PM, FrankHB1989 <=
span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com" target=3D"_bl=
ank">frankhb1989@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8815=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=8812:11:37=EF=BC=8CHyman Rosen=E5=86=
=99=E9=81=93=EF=BC=9A<span class=3D""><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">Well, no.=C2=A0 I believe that there should be no indet=
erminate rules on function invocation; like other expressions, evaluation s=
hould be strictly left-to-right, so that in=C2=A0<br><blockquote type=3D"ci=
te" style=3D"color:rgb(80,0,80);font-size:12.8px"><div dir=3D"ltr"><div cla=
ss=3D"gmail_quote"><table><tbody><tr><td style=3D"font-family:Consolas,&#39=
;Liberation Mono&#39;,Menlo,Courier,monospace;padding:0px 10px;vertical-ali=
gn:top;font-size:12px;white-space:pre-wrap;overflow:visible;word-wrap:norma=
l;background-color:rgb(248,238,199)"><span style=3D"color:rgb(0,134,179)">t=
extLayout</span>()-&gt;<span style=3D"color:rgb(0,134,179)">nextCursorPosit=
ion</span>(m_cursor) - m_cursor;</td></tr></tbody></table></div></div></blo=
ckquote><span style=3D"font-size:12.8px"><font color=3D"#000000">the first =
evaluation of m_cursor happens after textLayout() returns and the second ha=
ppens after nextCursorPosition() returns.=C2=A0 The only common sense requi=
red is the realization that it&#39;s common sense to require strict left-to=
-right order of evaluation, because even if that rule is surprising on firs=
t hearing, it&#39;s never surprising again.</font></span></div><div><br><br=
></div></blockquote><div>=C2=A0</div></span><div>Why need it to be common s=
ense? I&#39;m surprising this kind of rules should be inferred from elsewhe=
re.<br>=C2=A0<br></div><div>Well, even if learning with help of experience =
.... it should be knowledge of programming languages, not natural languages.=
 They are too different. Then:<br><ul><li>The rules are nonsense to one who=
 did not even know what is &quot;evaluation&quot;, which is more or less si=
milar in any practical programming languages.</li><li>Not all of them use t=
he same &quot;left-to-right&quot; rules, i.e. &quot;left-to-right&quot; is =
significantly restrictive and less &quot;common&quot; in this sense.</li><l=
i>So unless for some specific languages, &quot;left-to-right&quot; is happe=
ned to be, not expected to be.<br></li></ul><p>Keeping &quot;left-to-right&=
quot; common is not safe for people who need to work with multiple language=
s. For these users and beginners, keeping &quot;unspecific&quot; in mind is=
 sane and safer. (Or you will propose to change every programming languages=
 you see?)</p><p><br></p><p>And again, I see nothing that relying on the no=
t-so-common rules would benefit. (If any ... tolerance on buggy code?)</p><=
p><br></p><p><br></p>=C2=A0<br></div><div class=3D"HOEnZb"><div class=3D"h5=
">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1144082cff24d80526f23c45--

.

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

On Tue, Dec 15, 2015 at 4:25 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> The language rules for C++ are for C++ (and maybe C).  Requiring that C++
> must have built-in stupidity to match the built-in stupidity that people
> have learned in other languages leads to an insane downward spiral where
> nothing can be made better because people only know worse.  That is not a
> theory I accept.
>

Exactly! So there's no need for C++ to adopt the misfeatures of Java and
C#, just because some people are used to strict left-to-right evaluation
order.


> On Mon, Dec 14, 2015 at 10:30 PM, FrankHB1989 <frankhb1989@gmail.com>
> wrote:
>
>>
>>
>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=
 UTC+8=E4=B8=8A=E5=8D=8812:11:37=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=
=BC=9A
>>>
>>> Well, no.  I believe that there should be no indeterminate rules on
>>> function invocation; like other expressions, evaluation should be stric=
tly
>>> left-to-right, so that in
>>>
>>> textLayout()->nextCursorPosition(m_cursor) - m_cursor;
>>>
>>> the first evaluation of m_cursor happens after textLayout() returns and
>>> the second happens after nextCursorPosition() returns.  The only common
>>> sense required is the realization that it's common sense to require str=
ict
>>> left-to-right order of evaluation, because even if that rule is surpris=
ing
>>> on first hearing, it's never surprising again.
>>>
>>>
>>>
>> Why need it to be common sense? I'm surprising this kind of rules should
>> be inferred from elsewhere.
>>
>> Well, even if learning with help of experience ... it should be knowledg=
e
>> of programming languages, not natural languages. They are too different.
>> Then:
>>
>>    - The rules are nonsense to one who did not even know what is
>>    "evaluation", which is more or less similar in any practical programm=
ing
>>    languages.
>>    - Not all of them use the same "left-to-right" rules, i.e.
>>    "left-to-right" is significantly restrictive and less "common" in thi=
s
>>    sense.
>>    - So unless for some specific languages, "left-to-right" is happened
>>    to be, not expected to be.
>>
>> Keeping "left-to-right" common is not safe for people who need to work
>> with multiple languages. For these users and beginners, keeping
>> "unspecific" in mind is sane and safer. (Or you will propose to change
>> every programming languages you see?)
>>
>>
>> And again, I see nothing that relying on the not-so-common rules would
>> benefit. (If any ... tolerance on buggy code?)
>>
>>
>>
>>
>>
>> --
>>
>> ---
>> 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.
>> Visit this group at
>> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> 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/oQUOtYX4R3o/=
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.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--001a1140f62407eddc052702a2b2
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, Dec 15, 2015 at 4:25 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.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">The lang=
uage rules for C++ are for C++ (and maybe C).=C2=A0 Requiring that C++ must=
 have built-in stupidity to match the built-in stupidity that people have l=
earned in other languages leads to an insane downward spiral where nothing =
can be made better because people only know worse.=C2=A0 That is not a theo=
ry I accept.</div></blockquote><div><br></div><div>Exactly! So there&#39;s =
no need for C++ to adopt the misfeatures of Java and C#, just because some =
people are used to strict left-to-right evaluation order.</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 class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D"">On Mon, Dec 14, 2015 at 10:30 PM, FrankHB=
1989 <span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com" target=
=3D"_blank">frankhb1989@gmail.com</a>&gt;</span> wrote:<br></span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><span class=3D""><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=
=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=8812:11:3=
7=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">Well, no.=C2=A0 I believe that there sh=
ould be no indeterminate rules on function invocation; like other expressio=
ns, evaluation should be strictly left-to-right, so that in=C2=A0<br><block=
quote type=3D"cite" style=3D"color:rgb(80,0,80);font-size:12.8px"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><table><tbody><tr><td style=3D"font-fam=
ily:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;padding:0px =
10px;vertical-align:top;font-size:12px;white-space:pre-wrap;overflow:visibl=
e;word-wrap:normal;background-color:rgb(248,238,199)"><span style=3D"color:=
rgb(0,134,179)">textLayout</span>()-&gt;<span style=3D"color:rgb(0,134,179)=
">nextCursorPosition</span>(m_cursor) - m_cursor;</td></tr></tbody></table>=
</div></div></blockquote><span style=3D"font-size:12.8px"><font color=3D"#0=
00000">the first evaluation of m_cursor happens after textLayout() returns =
and the second happens after nextCursorPosition() returns.=C2=A0 The only c=
ommon sense required is the realization that it&#39;s common sense to requi=
re strict left-to-right order of evaluation, because even if that rule is s=
urprising on first hearing, it&#39;s never surprising again.</font></span><=
/div><div><br><br></div></blockquote><div>=C2=A0</div></span><div>Why need =
it to be common sense? I&#39;m surprising this kind of rules should be infe=
rred from elsewhere.<br>=C2=A0<br></div><div>Well, even if learning with he=
lp of experience ... it should be knowledge of programming languages, not n=
atural languages. They are too different. Then:<br><ul><li>The rules are no=
nsense to one who did not even know what is &quot;evaluation&quot;, which i=
s more or less similar in any practical programming languages.</li><li>Not =
all of them use the same &quot;left-to-right&quot; rules, i.e. &quot;left-t=
o-right&quot; is significantly restrictive and less &quot;common&quot; in t=
his sense.</li><li>So unless for some specific languages, &quot;left-to-rig=
ht&quot; is happened to be, not expected to be.<br></li></ul><p>Keeping &qu=
ot;left-to-right&quot; common is not safe for people who need to work with =
multiple languages. For these users and beginners, keeping &quot;unspecific=
&quot; in mind is sane and safer. (Or you will propose to change every prog=
ramming languages you see?)</p><p><br></p><p>And again, I see nothing that =
relying on the not-so-common rules would benefit. (If any ... tolerance on =
buggy code?)</p><p><br></p><p><br></p>=C2=A0<br></div></span><div><div>

<p></p>

-- <br>
<br>
--- <br><span class=3D"">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To 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>.<span class=3D""><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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div><div class=3D"HOEnZb"><div =
class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1140f62407eddc052702a2b2--

.

On Wednesday 16 December 2015 11:59:05 'Edward Catmur' via ISO C++ Standard -
Future Proposals wrote:
> Exactly! So there's no need for C++ to adopt the misfeatures of Java and
> C#, just because some people are used to strict left-to-right evaluation
> order.

Correct.

C++ should adopt the strict left-to-right evaluation if it improves C++.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Probably better to say

C++ should adopt the same left-to-right order as other languages _unless_ t=
here is better reason not to.=C2=A0

If two eval orders are essentially equal, go with the one everyone else use=
s.

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Thiago Macieira
Sent: Wednesday, December 16, 2015 8:56 AM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: About order of evaluation

On Wednesday 16 December 2015 11:59:05 'Edward Catmur' via ISO C++ Standard=
 -=20
Future Proposals wrote:
> Exactly! So there's no need for C++ to adopt the misfeatures of Java and
> C#, just because some people are used to strict left-to-right evaluation
> order.

Correct.

C++ should adopt the strict left-to-right evaluation if it improves C++.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

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

C++ should adopt strict left-to-right ordering in expression evaluation
because it is trivial to learn and understand, the current unspecified
order is confusing even to experts, it matches other parts of the language
that already use strict left-to-right ordering (e.g., initializers, comma
operators, statement sequences, et al.), it matches other programming
languages that derive syntax from C and C++ but have chosen this evaluation
order, and C++ code is written left-to-right.

C++ will not adopt strict left-to-right ordering in expression evaluation
because of code examples that may be compiled less efficiently in the new
regime, because the current system allows some people to feel clever, and
because, as in Stockholm Syndrome, C++ has come to identify with its abuser.

On Wed, Dec 16, 2015 at 10:05 AM, Tony V E <tvaneerd@gmail.com> wrote:

> Probably better to say
>
> C++ should adopt the same left-to-right order as other languages _unless_
> there is better reason not to.
>
> If two eval orders are essentially equal, go with the one everyone else
> uses.
>
> Sent from my BlackBerry portable Babbage Device
>   Original Message
> From: Thiago Macieira
> Sent: Wednesday, December 16, 2015 8:56 AM
> To: std-proposals@isocpp.org
> Reply To: std-proposals@isocpp.org
> Subject: Re: [std-proposals] Re: About order of evaluation
>
> On Wednesday 16 December 2015 11:59:05 'Edward Catmur' via ISO C++
> Standard -
> Future Proposals wrote:
> > Exactly! So there's no need for C++ to adopt the misfeatures of Java and
> > C#, just because some people are used to strict left-to-right evaluation
> > order.
>
> Correct.
>
> C++ should adopt the strict left-to-right evaluation if it improves C++.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">C++ should adopt strict left-to-right ordering in expressi=
on evaluation because it is trivial to learn and understand, the current un=
specified order is confusing even to experts, it matches other parts of the=
 language that already use strict left-to-right ordering (e.g., initializer=
s, comma operators, statement sequences, et al.), it matches other programm=
ing languages that derive syntax from C and C++ but have chosen this evalua=
tion order, and C++ code is written left-to-right.<br><br>C++ will not adop=
t=C2=A0strict left-to-right ordering in expression evaluation because of co=
de examples that may be compiled less efficiently in the new regime, becaus=
e the current system allows some people to feel clever, and because, as in =
Stockholm Syndrome, C++ has come to identify with its abuser.</div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Dec 16, 2015 at 1=
0:05 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.co=
m" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</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">Probably better to say<br>
<br>
C++ should adopt the same left-to-right order as other languages _unless_ t=
here is better reason not to.=C2=A0<br>
<br>
If two eval orders are essentially equal, go with the one everyone else use=
s.<br>
<span class=3D""><br>
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce<br>
</span>=C2=A0 Original Message =C2=A0<br>
From: Thiago Macieira<br>
Sent: Wednesday, December 16, 2015 8:56 AM<br>
To: <a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a=
><br>
Reply To: <a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.=
org</a><br>
Subject: Re: [std-proposals] Re: About order of evaluation<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Wednesday 16 December 2015 11:59:05 &#39;Edward Catmur&#39; via ISO C++ =
Standard -<br>
Future Proposals wrote:<br>
&gt; Exactly! So there&#39;s no need for C++ to adopt the misfeatures of Ja=
va and<br>
&gt; C#, just because some people are used to strict left-to-right evaluati=
on<br>
&gt; order.<br>
<br>
Correct.<br>
<br>
C++ should adopt the strict left-to-right evaluation if it improves C++.<br=
>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
Software Architect - Intel Open Source Technology Center<br>
PGP/GPG: 0x6EF45358; fingerprint:<br>
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1144082c63cee2052707e3e3--

.

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

On Wed, Dec 16, 2015 at 6:14 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> C++ should adopt strict left-to-right ordering in expression evaluation
> because it is trivial to learn and understand, the current unspecified
> order is confusing even to experts, it matches other parts of the language
> that already use strict left-to-right ordering (e.g., initializers, comma
> operators, statement sequences, et al.), it matches other programming
> languages that derive syntax from C and C++ but have chosen this evaluation
> order, and C++ code is written left-to-right.
>

.... except for types in declarators, and numbers, obviously. Also, I assume
you would retain the short-circuiting behavior of the logical and ternary
conditional operators. And don't forget that the arguments to an inline
lambda will be evaluated before the body of the lambda function is entered,
so those aren't strict left-to-right either.


> C++ will not adopt strict left-to-right ordering in expression evaluation
> because of code examples that may be compiled less efficiently in the new
> regime, because the current system allows some people to feel clever, and
> because, as in Stockholm Syndrome, C++ has come to identify with its abuser.
>

"Code examples" insinuates that such items are contrived. "Existing code"
would be more neutral, I think. A few more points: that code depending on
evaluation order is (generally) unclear and overcomplicated and should not
be encouraged; and that a high-level language should empower the user to
express *what* the program should do, not *how* it should do it, with
unspecified evaluation order tending towards the former and strict
left-to-right evaluation order encouraging the latter, even when it is not
intended.

With SMP systems now the default at most scales, the concept of
indeterminate sequencing of side effects should be familiar to most users.
Indeed, with transactional memory becoming available on commodity hardware
it is surely only a matter of time before speculative multithreading moves
from academia to becoming a standard compiler technique; the more that
C++'s evaluation order is "nailed down", the less it will be amenable to
these optimization techniques.

The problem is that this is an irrevocable decision; if evaluation order
were to be made strict, it would be very difficult later to relax it. A
similar objection holds in the small; right now, it is easy to guarantee a
particular evaluation order of a piece of code, as you have covered above;
however under the proposals there would be no way explicitly to relax the
evaluation order among a collection of subexpressions.

On Wed, Dec 16, 2015 at 10:05 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>> Probably better to say
>>
>> C++ should adopt the same left-to-right order as other languages _unless_
>> there is better reason not to.
>>
>> If two eval orders are essentially equal, go with the one everyone else
>> uses.
>>
>> Sent from my BlackBerry portable Babbage Device
>>   Original Message
>> From: Thiago Macieira
>> Sent: Wednesday, December 16, 2015 8:56 AM
>> To: std-proposals@isocpp.org
>> Reply To: std-proposals@isocpp.org
>> Subject: Re: [std-proposals] Re: About order of evaluation
>>
>> On Wednesday 16 December 2015 11:59:05 'Edward Catmur' via ISO C++
>> Standard -
>> Future Proposals wrote:
>> > Exactly! So there's no need for C++ to adopt the misfeatures of Java and
>> > C#, just because some people are used to strict left-to-right evaluation
>> > order.
>>
>> Correct.
>>
>> C++ should adopt the strict left-to-right evaluation if it improves C++.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>> PGP/GPG: 0x6EF45358; fingerprint:
>> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> 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/oQUOtYX4R3o/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.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1140c20c285fa505270bdcad
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, Dec 16, 2015 at 6:14 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.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">C++ shou=
ld adopt strict left-to-right ordering in expression evaluation because it =
is trivial to learn and understand, the current unspecified order is confus=
ing even to experts, it matches other parts of the language that already us=
e strict left-to-right ordering (e.g., initializers, comma operators, state=
ment sequences, et al.), it matches other programming languages that derive=
 syntax from C and C++ but have chosen this evaluation order, and C++ code =
is written left-to-right.<br></div></blockquote><div><br></div><div>... exc=
ept for types in declarators, and numbers, obviously. Also, I assume you wo=
uld retain the short-circuiting behavior of the logical and ternary conditi=
onal operators. And don&#39;t forget that the arguments to an inline lambda=
 will be evaluated before the body of the lambda function is entered, so th=
ose aren&#39;t strict left-to-right either.</div><div>=C2=A0</div><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">C++ will not adopt=C2=A0strict left-=
to-right ordering in expression evaluation because of code examples that ma=
y be compiled less efficiently in the new regime, because the current syste=
m allows some people to feel clever, and because, as in Stockholm Syndrome,=
 C++ has come to identify with its abuser.</div></blockquote><div><br></div=
><div>&quot;Code examples&quot; insinuates that such items are contrived. &=
quot;Existing code&quot; would be more neutral, I think. A few more points:=
 that code depending on evaluation order is (generally) unclear and overcom=
plicated and should not be encouraged; and that a high-level language shoul=
d empower the user to express *what* the program should do, not *how* it sh=
ould do it, with unspecified evaluation order tending towards the former an=
d strict left-to-right evaluation order encouraging the latter, even when i=
t is not intended.</div><div><br></div><div>With SMP systems now the defaul=
t at most scales, the concept of indeterminate sequencing of side effects s=
hould be familiar to most users. Indeed, with transactional memory becoming=
 available on commodity hardware it is surely only a matter of time before =
speculative multithreading moves from academia to becoming a standard compi=
ler technique; the more that C++&#39;s evaluation order is &quot;nailed dow=
n&quot;, the less it will be amenable to these optimization techniques.</di=
v><div><br></div><div>The problem is that this is an irrevocable decision; =
if evaluation order were to be made strict, it would be very difficult late=
r to relax it. A similar objection holds in the small; right now, it is eas=
y to guarantee a particular evaluation order of a piece of code, as you hav=
e covered above; however under the proposals there would be no way explicit=
ly to relax the evaluation order among a collection of subexpressions.</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div c=
lass=3D"h5"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, D=
ec 16, 2015 at 10:05 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:t=
vaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Probably better to say<br>
<br>
C++ should adopt the same left-to-right order as other languages _unless_ t=
here is better reason not to.=C2=A0<br>
<br>
If two eval orders are essentially equal, go with the one everyone else use=
s.<br>
<span><br>
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce<br>
</span>=C2=A0 Original Message =C2=A0<br>
From: Thiago Macieira<br>
Sent: Wednesday, December 16, 2015 8:56 AM<br>
To: <a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-propo=
sals@isocpp.org</a><br>
Reply To: <a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std=
-proposals@isocpp.org</a><br>
Subject: Re: [std-proposals] Re: About order of evaluation<br>
<div><div><br>
On Wednesday 16 December 2015 11:59:05 &#39;Edward Catmur&#39; via ISO C++ =
Standard -<br>
Future Proposals wrote:<br>
&gt; Exactly! So there&#39;s no need for C++ to adopt the misfeatures of Ja=
va and<br>
&gt; C#, just because some people are used to strict left-to-right evaluati=
on<br>
&gt; order.<br>
<br>
Correct.<br>
<br>
C++ should adopt the strict left-to-right evaluation if it improves C++.<br=
>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
Software Architect - Intel Open Source Technology Center<br>
PGP/GPG: 0x6EF45358; fingerprint:<br>
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1140c20c285fa505270bdcad--

.

------=_Part_146_541674349.1450322495391
Content-Type: multipart/alternative;
 boundary="----=_Part_147_1181709713.1450322495392"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8A=E5=8D=8812:25:33=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>
> The language rules for C++ are for C++ (and maybe C).  Requiring that C++=
=20
> must have built-in stupidity to match the built-in stupidity that people=
=20
> have learned in other languages leads to an insane downward spiral where=
=20
> nothing can be made better because people only know worse.  That is not a=
=20
> theory I accept.
>
> Probably C would be more reluctant to accept these changes. In fact C11=
=20
has copied wording from C++11 to clarify the evaluation rules (though it=20
keeps "sequence points" as well), but there are no such changes like CWG222=
=20
<http://wg21.cmeerw.net/cwg/issue222>. So if C++ changes, things would be=
=20
even worse...

What is stupid? Expressiveness?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8816=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:25:33=EF=BC=8CHyman Rose=
n=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;"><d=
iv dir=3D"ltr">The language rules for C++ are for C++ (and maybe C).=C2=A0 =
Requiring that C++ must have built-in stupidity to match the built-in stupi=
dity that people have learned in other languages leads to an insane downwar=
d spiral where nothing can be made better because people only know worse.=
=C2=A0 That is not a theory I accept.</div><div><br></div></blockquote><div=
>Probably C would be more reluctant to accept these changes. In fact C11 ha=
s copied wording from C++11 to clarify the evaluation rules (though it keep=
s &quot;sequence points&quot; as well), but there are no such changes like =
<a href=3D"http://wg21.cmeerw.net/cwg/issue222">CWG222</a>. So if C++ chang=
es, things would be even worse...<br><br>What is stupid? Expressiveness?<br=
><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_147_1181709713.1450322495392--
------=_Part_146_541674349.1450322495391--

.

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

On Wed, Dec 16, 2015 at 5:59 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> ... except for types in declarators, and numbers, obviously.
>>
>
I don't understand what this means.

Also, I assume you would retain the short-circuiting behavior of the
>> logical and ternary conditional operators.
>>
>
Of course.  I have previously proposed, informally, that it should be
possible to annotate a function parameter declaration something like this, void
f([] int i), such that at the call site the argument expression would be
packaged into a (special type of) lambda which would only be evaluated
inside f when called for.  This would allow user code to create its own
short-circuit forms, including finally the ability to properly overload
operator&& and operator|| while preserving short-circuit semantics.  (These
lambdas need to be special because every ordinary lambda has a different
type, which would force f to become a template.)

And don't forget that the arguments to an inline lambda will be evaluated
>> before the body of the lambda function is entered, so those aren't strict
>> left-to-right either.
>>
>
But a function definition is never evaluated; a function is executed only
as part of a call expression.  A braced sequence of code is not an
expression.

"Code examples" insinuates that such items are contrived. "Existing code"
> would be more neutral, I think.
>

The code examples are not necessarily contrived, but they're diligently
searched for, precisely to head off the possibility of strictly defining
order of evaluation.


> A few more points: that code depending on evaluation order is (generally)
> unclear and overcomplicated and should not be encouraged; and that a
> high-level language should empower the user to express *what* the program
> should do, not *how* it should do it, with unspecified evaluation order
> tending towards the former and strict left-to-right evaluation order
> encouraging the latter, even when it is not intended.
>

No, this is exactly backwards.  The reason such code appears unclear and
overcomplicated is because the language has failed to define what the code
does.  You are correct that code should specify what the program should do;
language rules that refuse to define what code means get in the way between
what the program expresses and what the program does.  The only reason for
thinking that leaving order of evaluation unspecified is good is because of
Stockholm Syndrome - it has been this way for so long that people have
found reasons for believing this way is right rather than fighting against
it.  But leaving the order of evaluation of f(a(), b()) unspecified should
feel as horrifying as if the language were to say that a(); b(); had
unspecified order.


> With SMP systems now the default at most scales, the concept of
> indeterminate sequencing of side effects should be familiar to most users.
> Indeed, with transactional memory becoming available on commodity hardware
> it is surely only a matter of time before speculative multithreading moves
> from academia to becoming a standard compiler technique; the more that
> C++'s evaluation order is "nailed down", the less it will be amenable to
> these optimization techniques.
>

The problem is that a programming language is meant to express instructions
to a machine.  Letting the language be ambiguous leads to errors, not
efficiencies.  The compiler does not know whether the ambiguity you have
placed into your code is deliberate or wrong, and chooses to think it's the
former.  If there are circumstances where ambiguous order is desirable, the
programming language should provide a means for the programmer to
explicitly say so.  (And no, f((a(), 0), (b(), 0)) is not the way.)


>
> The problem is that this is an irrevocable decision; if evaluation order
> were to be made strict, it would be very difficult later to relax it. A
> similar objection holds in the small; right now, it is easy to guarantee a
> particular evaluation order of a piece of code, as you have covered above;
> however under the proposals there would be no way explicitly to relax the
> evaluation order among a collection of subexpressions.
>

I would be fine with there being no such way, or with having some piece of
standout syntax to indicate it.  This is how the (implementation-dependent)
branch-prediction syntax works; you sprinkle your code with
__builtin_expect when
you want to tell the compiler how you think a branch will go.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1143fae0d4977b05271c3ecf
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, Dec 16, 2015 at 5:59 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-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"><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">... e=
xcept for types in declarators, and numbers, obviously.</div></blockquote><=
/span></div></div></div></blockquote><div><br>I don&#39;t understand what t=
his means.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><span class=3D""><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"> Also, I assume you would retain the short-circuiting behavior=
 of the logical and ternary conditional operators.</div></blockquote></span=
></div></div></div></blockquote><div><br>Of course.=C2=A0 I have previously=
 proposed, informally, that it should be possible to annotate a function pa=
rameter declaration something like this, <font face=3D"monospace, monospace=
">void f([] int i)</font>, such that at the call site the argument expressi=
on would be packaged into a (special type of) lambda which would only be ev=
aluated inside <font face=3D"monospace, monospace">f</font> when called for=
..=C2=A0 This would allow user code to create its own short-circuit forms, i=
ncluding finally the ability to properly overload <font face=3D"monospace, =
monospace">operator&amp;&amp;</font> and <font face=3D"monospace, monospace=
">operator||</font> while preserving short-circuit semantics. =C2=A0(These =
lambdas need to be special because every ordinary lambda has a different ty=
pe, which would force=C2=A0<span style=3D"font-family:monospace,monospace">=
f</span>=C2=A0to become a template.)<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-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"><span class=
=3D""><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"> And don&#39;t forget that the argu=
ments to an inline lambda will be evaluated before the body of the lambda f=
unction is entered, so those aren&#39;t strict left-to-right either.<br></d=
iv></blockquote></span></div></div></div></blockquote><div><br>But a functi=
on definition is never evaluated; a function is executed only as part of a =
call expression.=C2=A0 A braced sequence of code is not an expression.<br><=
br></div><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"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div>&quot;Code examples&quot; insinuates that such i=
tems are contrived. &quot;Existing code&quot; would be more neutral, I thin=
k.</div></div></div></div></blockquote><div><br>The code examples are not n=
ecessarily contrived, but they&#39;re diligently searched for, precisely to=
 head off the possibility of strictly defining order of evaluation.<br>=C2=
=A0</div><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"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div> A few more points: that code depending on evalu=
ation order is (generally) unclear and overcomplicated and should not be en=
couraged; and that a high-level language should empower the user to express=
 *what* the program should do, not *how* it should do it, with unspecified =
evaluation order tending towards the former and strict left-to-right evalua=
tion order encouraging the latter, even when it is not intended.</div></div=
></div></div></blockquote><div><br>No, this is exactly backwards.=C2=A0 The=
 reason such code appears unclear and overcomplicated is because the langua=
ge has failed to define what the code does.=C2=A0 You are correct that code=
 should specify what the program should do; language rules that refuse to d=
efine what code means get in the way between what the program expresses and=
 what the program does.=C2=A0 The only reason for thinking that leaving ord=
er of evaluation unspecified is good is because of Stockholm Syndrome - it =
has been this way for so long that people have found reasons for believing =
this way is right rather than fighting against it.=C2=A0 But leaving the or=
der of evaluation of <font face=3D"monospace, monospace">f(a(), b())</font>=
 unspecified should feel as horrifying as if the language were to say that =
<font face=3D"monospace, monospace">a(); b();</font> had unspecified order.=
<br>=C2=A0</div><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"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div>With SMP systems now the default at most =
scales, the concept of indeterminate sequencing of side effects should be f=
amiliar to most users. Indeed, with transactional memory becoming available=
 on commodity hardware it is surely only a matter of time before speculativ=
e multithreading moves from academia to becoming a standard compiler techni=
que; the more that C++&#39;s evaluation order is &quot;nailed down&quot;, t=
he less it will be amenable to these optimization techniques.</div></div></=
div></div></blockquote><div><br>The problem is that a programming language =
is meant to express instructions to a machine.=C2=A0 Letting the language b=
e ambiguous leads to errors, not efficiencies.=C2=A0 The compiler does not =
know whether the ambiguity you have placed into your code is deliberate or =
wrong, and chooses to think it&#39;s the former.=C2=A0 If there are circums=
tances where ambiguous order is desirable, the programming language should =
provide a means for the programmer to explicitly say so. =C2=A0(And no, <fo=
nt face=3D"monospace, monospace">f((a(), 0), (b(), 0))</font> is not the wa=
y.)<br>=C2=A0</div><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"><div><br></div><div>The problem is that thi=
s is an irrevocable decision; if evaluation order were to be made strict, i=
t would be very difficult later to relax it. A similar objection holds in t=
he small; right now, it is easy to guarantee a particular evaluation order =
of a piece of code, as you have covered above; however under the proposals =
there would be no way explicitly to relax the evaluation order among a coll=
ection of subexpressions.</div></div></div></div></blockquote><div><br>I wo=
uld be fine with there being no such way, or with having some piece of stan=
dout syntax to indicate it.=C2=A0 This is how the (implementation-dependent=
) branch-prediction syntax works; you sprinkle your code with=C2=A0<span st=
yle=3D"color:rgb(0,0,0);white-space:inherit;font-size:13px;background-color=
:rgb(255,255,255)"><font face=3D"monospace, monospace">__builtin_expect</fo=
nt></span><span style=3D"color:rgb(0,0,0);white-space:inherit;font-size:13p=
x;background-color:rgb(255,255,255)"><font face=3D"arial, helvetica, sans-s=
erif">=C2=A0when you want to tell the compiler how you think a branch will =
go.</font></span></div></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1143fae0d4977b05271c3ecf--

.

On 12/17/2015 07:32 PM, Hyman Rosen wrote:
> The problem is that a programming language is meant to express
> instructions to a machine.  Letting the language be ambiguous leads
> to errors, not efficiencies.  The compiler does not know whether the
> ambiguity you have placed into your code is deliberate or wrong, and
> chooses to think it's the former.  If there are circumstances where
> ambiguous order is desirable, the programming language should provide
> a means for the programmer to explicitly say so.  (And no, f((a(),
> 0), (b(), 0)) is not the way.)

In general, the reason why C++ (and C) leave certain source code
constructs as "undefined" or "unspecified" is to enable
machine-level efficiency and error detection.

For example, signed integer overflow is undefined because the
alternative (defining it to two's complement wraparound) has
surprising cost on non-two's complement machines (which existed
at some time in history), and would prevent compilers from
instrumenting your code to trap on signed integer overflow
(if desired for debugging/safety purposes).

With the order-of-evaluation question, I'm seeing arguments
that certain C++ source code patterns lead to surprising
program behavior due to lack of sequencing.  Regrettably,
I'm seeing not a lot of data points how much the addition
of some more sequencing costs us in terms of performance.
I understand this is a difficult question to answer, because
 - It depends.
 - We need to modify a compiler first and then test a large
codebase (SPEC?) for effects.
 - We might not see a lot of effect, because current optimizer
technology doesn't exploit order-of-evaluation freedom as
aggressively as might be beneficial.

So, it's not "obviously" right to specify the order-of-evaluation
pervasively, and neither is it "obviously" right to retain the
status quo.

As a historic consideration, the C++ standard contained rules for
type-based alias analysis since the onset (3.10p10), but
(at least for my compiler), it took well into the last decade
before it was exploited for optimization.  And that did (and does)
break quite a bit of code.  What would have happened if someone
had proposed removing 3.10p10 in the year 2000, for example?
After all, these are somewhat confusing rules, which, at that time,
didn't have measurable performance impact, but nowadays everybody
is probably happy to have those rules.

Thanks,
Jens

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

The point Jonathan Caves (and more recently Myriachan) made of such things
as (new X)->f() being a priori unordered does strike a pain point. I'm not
convinced we should order every expression (due to potential optimizer
hindrance; please, optimizer people, correct me if I'm wrong) but this
particular one is really annoying.

2015-12-17 16:04 GMT-05:00 Jens Maurer <Jens.Maurer@gmx.net>:

> On 12/17/2015 07:32 PM, Hyman Rosen wrote:
> > The problem is that a programming language is meant to express
> > instructions to a machine.  Letting the language be ambiguous leads
> > to errors, not efficiencies.  The compiler does not know whether the
> > ambiguity you have placed into your code is deliberate or wrong, and
> > chooses to think it's the former.  If there are circumstances where
> > ambiguous order is desirable, the programming language should provide
> > a means for the programmer to explicitly say so.  (And no, f((a(),
> > 0), (b(), 0)) is not the way.)
>
> In general, the reason why C++ (and C) leave certain source code
> constructs as "undefined" or "unspecified" is to enable
> machine-level efficiency and error detection.
>
> For example, signed integer overflow is undefined because the
> alternative (defining it to two's complement wraparound) has
> surprising cost on non-two's complement machines (which existed
> at some time in history), and would prevent compilers from
> instrumenting your code to trap on signed integer overflow
> (if desired for debugging/safety purposes).
>
> With the order-of-evaluation question, I'm seeing arguments
> that certain C++ source code patterns lead to surprising
> program behavior due to lack of sequencing.  Regrettably,
> I'm seeing not a lot of data points how much the addition
> of some more sequencing costs us in terms of performance.
> I understand this is a difficult question to answer, because
>  - It depends.
>  - We need to modify a compiler first and then test a large
> codebase (SPEC?) for effects.
>  - We might not see a lot of effect, because current optimizer
> technology doesn't exploit order-of-evaluation freedom as
> aggressively as might be beneficial.
>
> So, it's not "obviously" right to specify the order-of-evaluation
> pervasively, and neither is it "obviously" right to retain the
> status quo.
>
> As a historic consideration, the C++ standard contained rules for
> type-based alias analysis since the onset (3.10p10), but
> (at least for my compiler), it took well into the last decade
> before it was exploited for optimization.  And that did (and does)
> break quite a bit of code.  What would have happened if someone
> had proposed removing 3.10p10 in the year 2000, for example?
> After all, these are somewhat confusing rules, which, at that time,
> didn't have measurable performance impact, but nowadays everybody
> is probably happy to have those rules.
>
> Thanks,
> Jens
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">The point Jonathan Caves (and more recently Myriachan) mad=
e of such things as (new X)-&gt;f() being a priori unordered does strike a =
pain point. I&#39;m not convinced we should order every expression (due to =
potential optimizer hindrance; please, optimizer people, correct me if I&#3=
9;m wrong) but this particular one is really annoying.<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-12-17 16:04 GMT-05:00 =
Jens Maurer <span dir=3D"ltr">&lt;<a href=3D"mailto:Jens.Maurer@gmx.net" ta=
rget=3D"_blank">Jens.Maurer@gmx.net</a>&gt;</span>:<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 12/17/2015 07:32 PM, Hyman Rosen wrote:<br>
&gt; The problem is that a programming language is meant to express<br>
&gt; instructions to a machine.=C2=A0 Letting the language be ambiguous lea=
ds<br>
&gt; to errors, not efficiencies.=C2=A0 The compiler does not know whether =
the<br>
&gt; ambiguity you have placed into your code is deliberate or wrong, and<b=
r>
&gt; chooses to think it&#39;s the former.=C2=A0 If there are circumstances=
 where<br>
&gt; ambiguous order is desirable, the programming language should provide<=
br>
&gt; a means for the programmer to explicitly say so.=C2=A0 (And no, f((a()=
,<br>
&gt; 0), (b(), 0)) is not the way.)<br>
<br>
</span>In general, the reason why C++ (and C) leave certain source code<br>
constructs as &quot;undefined&quot; or &quot;unspecified&quot; is to enable=
<br>
machine-level efficiency and error detection.<br>
<br>
For example, signed integer overflow is undefined because the<br>
alternative (defining it to two&#39;s complement wraparound) has<br>
surprising cost on non-two&#39;s complement machines (which existed<br>
at some time in history), and would prevent compilers from<br>
instrumenting your code to trap on signed integer overflow<br>
(if desired for debugging/safety purposes).<br>
<br>
With the order-of-evaluation question, I&#39;m seeing arguments<br>
that certain C++ source code patterns lead to surprising<br>
program behavior due to lack of sequencing.=C2=A0 Regrettably,<br>
I&#39;m seeing not a lot of data points how much the addition<br>
of some more sequencing costs us in terms of performance.<br>
I understand this is a difficult question to answer, because<br>
=C2=A0- It depends.<br>
=C2=A0- We need to modify a compiler first and then test a large<br>
codebase (SPEC?) for effects.<br>
=C2=A0- We might not see a lot of effect, because current optimizer<br>
technology doesn&#39;t exploit order-of-evaluation freedom as<br>
aggressively as might be beneficial.<br>
<br>
So, it&#39;s not &quot;obviously&quot; right to specify the order-of-evalua=
tion<br>
pervasively, and neither is it &quot;obviously&quot; right to retain the<br=
>
status quo.<br>
<br>
As a historic consideration, the C++ standard contained rules for<br>
type-based alias analysis since the onset (3.10p10), but<br>
(at least for my compiler), it took well into the last decade<br>
before it was exploited for optimization.=C2=A0 And that did (and does)<br>
break quite a bit of code.=C2=A0 What would have happened if someone<br>
had proposed removing 3.10p10 in the year 2000, for example?<br>
After all, these are somewhat confusing rules, which, at that time,<br>
didn&#39;t have measurable performance impact, but nowadays everybody<br>
is probably happy to have those rules.<br>
<br>
Thanks,<br>
Jens<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113ecbba53af1005272195b2--

.

On Thursday 17 December 2015 19:54:35 Patrice Roy wrote:
> The point Jonathan Caves (and more recently Myriachan) made of such things
> as (new X)->f() being a priori unordered does strike a pain point. I'm not
> convinced we should order every expression (due to potential optimizer
> hindrance; please, optimizer people, correct me if I'm wrong) but this
> particular one is really annoying.

How can (new X)->f() not be ordered? The new needs to happen before the call
to X::f(), as the result from the new is required  as a parameter to the call
to X::f().
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-12-18 13:21, Thiago Macieira wrote:
> On Thursday 17 December 2015 19:54:35 Patrice Roy wrote:
>> The point Jonathan Caves (and more recently Myriachan) made of such things
>> as (new X)->f() being a priori unordered does strike a pain point. I'm not
>> convinced we should order every expression (due to potential optimizer
>> hindrance; please, optimizer people, correct me if I'm wrong) but this
>> particular one is really annoying.
>
> How can (new X)->f() not be ordered? The new needs to happen before the call
> to X::f(), as the result from the new is required  as a parameter to the call
> to X::f().

IIRC, the "correct" example is:

  (new X)->f(b());

The 'new X' and 'b()' are not ordered.

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

Thanks; wrote it late yesterday!

2015-12-18 13:38 GMT-05:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:

> On 2015-12-18 13:21, Thiago Macieira wrote:
> > On Thursday 17 December 2015 19:54:35 Patrice Roy wrote:
> >> The point Jonathan Caves (and more recently Myriachan) made of such
> things
> >> as (new X)->f() being a priori unordered does strike a pain point. I'm
> not
> >> convinced we should order every expression (due to potential optimizer
> >> hindrance; please, optimizer people, correct me if I'm wrong) but this
> >> particular one is really annoying.
> >
> > How can (new X)->f() not be ordered? The new needs to happen before the
> call
> > to X::f(), as the result from the new is required  as a parameter to the
> call
> > to X::f().
>
> IIRC, the "correct" example is:
>
>   (new X)->f(b());
>
> The 'new X' and 'b()' are not ordered.
>
> --
> 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.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Thanks; wrote it late yesterday!<br></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">2015-12-18 13:38 GMT-05:00 Matthe=
w Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com"=
 target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span>:<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 2015-12-18 13:21, Thiago Macieira wr=
ote:<br>
&gt; On Thursday 17 December 2015 19:54:35 Patrice Roy wrote:<br>
&gt;&gt; The point Jonathan Caves (and more recently Myriachan) made of suc=
h things<br>
&gt;&gt; as (new X)-&gt;f() being a priori unordered does strike a pain poi=
nt. I&#39;m not<br>
&gt;&gt; convinced we should order every expression (due to potential optim=
izer<br>
&gt;&gt; hindrance; please, optimizer people, correct me if I&#39;m wrong) =
but this<br>
&gt;&gt; particular one is really annoying.<br>
&gt;<br>
&gt; How can (new X)-&gt;f() not be ordered? The new needs to happen before=
 the call<br>
&gt; to X::f(), as the result from the new is required=C2=A0 as a parameter=
 to the call<br>
&gt; to X::f().<br>
<br>
</span>IIRC, the &quot;correct&quot; example is:<br>
<br>
=C2=A0 (new X)-&gt;f(b());<br>
<br>
The &#39;new X&#39; and &#39;b()&#39; are not ordered.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1141bb98df60180527316730--

.

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

On Thu, Dec 17, 2015 at 6:32 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Wed, Dec 16, 2015 at 5:59 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>> ... except for types in declarators, and numbers, obviously.
> I don't understand what this means.

The declarator syntax is widely considered confusing and nonlinear where
pointer, array and function types are concerned; this is only partially
alleviated by delayed return types and using-declarations (replacing
typedef, which is again widely considered to be backward). Numbers are
written right-to-left because place notation was introduced to Europe via
Arabic.

>> And don't forget that the arguments to an inline lambda will be
evaluated before the body of the lambda function is entered, so those
aren't strict left-to-right either.
> But a function definition is never evaluated; a function is executed only
as part of a call expression.  A braced sequence of code is not an
expression.

That's a pedantic distinction; the statements within the lambda function
definition are evaluated whenever the enclosing expression is evaluated.

> The code examples are not necessarily contrived, but they're diligently
searched for, precisely to head off the possibility of strictly defining
order of evaluation.

Not that diligently, I assure you.

> No, this is exactly backwards.  The reason such code appears unclear and
overcomplicated is because the language has failed to define what the code
does.

Coding guidelines recommend against expressions with multiple side effects
even in languages with strict order of evaluation.

> You are correct that code should specify what the program should do;
language rules that refuse to define what code means get in the way between
what the program expresses and what the program does.

Yes, and this is a good thing; it frees the user to think at a higher level
of abstraction, and the compiler to choose the most efficient
implementation.

> The problem is that a programming language is meant to express
instructions to a machine.  Letting the language be ambiguous leads to
errors, not efficiencies.  The compiler does not know whether the ambiguity
you have placed into your code is deliberate or wrong, and chooses to think
it's the former.  If there are circumstances where ambiguous order is
desirable, the programming language should provide a means for the
programmer to explicitly say so.  (And no, f((a(), 0), (b(), 0)) is not the
way.)

No, programming languages express a computation, which may be an algorithm,
a function, a query or so on, and allow the compiler to choose among
appropriate sequences of machine instructions. If you want to write machine
instructions, program in assembler. Or Forth.

Ambiguity is *always* desirable, as it is a prerequisite for any
optimization; there must be multiple possible implementations for there to
be any choosing between them.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<p dir=3D"ltr"><br>
On Thu, Dec 17, 2015 at 6:32 PM, Hyman Rosen &lt;<a href=3D"mailto:hyman.ro=
sen@gmail.com">hyman.rosen@gmail.com</a>&gt; wrote:<br>
&gt; On Wed, Dec 16, 2015 at 5:59 PM, &#39;Edward Catmur&#39; via ISO C++ S=
tandard - Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">=
std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;&gt; ... except for types in declarators, and numbers, obviously.<br>
&gt; I don&#39;t understand what this means.</p>
<p dir=3D"ltr">The declarator syntax is widely considered confusing and non=
linear where pointer, array and function types are concerned; this is only =
partially alleviated by delayed return types and using-declarations (replac=
ing typedef, which is again widely considered to be backward). Numbers are =
written right-to-left because place notation was introduced to Europe via A=
rabic.<br>
=C2=A0<br>
&gt;&gt; And don&#39;t forget that the arguments to an inline lambda will b=
e evaluated before the body of the lambda function is entered, so those are=
n&#39;t strict left-to-right either.<br>
&gt; But a function definition is never evaluated; a function is executed o=
nly as part of a call expression.=C2=A0 A braced sequence of code is not an=
 expression.</p>
<p dir=3D"ltr">That&#39;s a pedantic distinction; the statements within the=
 lambda function definition are evaluated whenever the enclosing expression=
 is evaluated.=C2=A0</p>
<p dir=3D"ltr">&gt; The code examples are not necessarily contrived, but th=
ey&#39;re diligently searched for, precisely to head off the possibility of=
 strictly defining order of evaluation.=C2=A0</p>
<p dir=3D"ltr">Not that diligently, I assure you.</p>
<p dir=3D"ltr">&gt; No, this is exactly backwards.=C2=A0 The reason such co=
de appears unclear and overcomplicated is because the language has failed t=
o define what the code does.=C2=A0</p>
<p dir=3D"ltr">Coding guidelines recommend against expressions with multipl=
e side effects even in languages with strict order of evaluation.<br>
=C2=A0<br>
&gt; You are correct that code should specify what the program should do; l=
anguage rules that refuse to define what code means get in the way between =
what the program expresses and what the program does.=C2=A0</p>
<p dir=3D"ltr">Yes, and this is a good thing; it frees the user to think at=
 a higher level of abstraction, and the compiler to choose the most efficie=
nt implementation. <br>
=C2=A0<br>
&gt; The problem is that a programming language is meant to express instruc=
tions to a machine.=C2=A0 Letting the language be ambiguous leads to errors=
, not efficiencies.=C2=A0 The compiler does not know whether the ambiguity =
you have placed into your code is deliberate or wrong, and chooses to think=
 it&#39;s the former.=C2=A0 If there are circumstances where ambiguous orde=
r is desirable, the programming language should provide a means for the pro=
grammer to explicitly say so. =C2=A0(And no, f((a(), 0), (b(), 0)) is not t=
he way.)</p>
<p dir=3D"ltr">No, programming languages express a computation, which may b=
e an algorithm, a function, a query or so on, and allow the compiler to cho=
ose among appropriate sequences of machine instructions. If you want to wri=
te machine instructions, program in assembler. Or Forth. </p>
<p dir=3D"ltr">Ambiguity is *always* desirable, as it is a prerequisite for=
 any optimization; there must be multiple possible implementations for ther=
e to be any choosing between them.<br>
</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113ed14add56ca052731d40b--

.

------=_Part_7_851807324.1450514956019
Content-Type: multipart/alternative;
 boundary="----=_Part_8_1941904909.1450514956019"

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

Le vendredi 18 d=C3=A9cembre 2015 21:17:43 UTC+1, Edward Catmur a =C3=A9cri=
t :
>
>
> Ambiguity is *always* desirable, as it is a prerequisite for any=20
> optimization; there must be multiple possible implementations for there t=
o=20
> be any choosing between them.
>

That  affirmation "ambiguity is a prerequisite for any optimization" is=20
visibly overreaching.  The as-if rule gives already quite a lot of=20
opportunity and in fact I wonder how much is there in practice which is not=
=20
covered by the as-if rule.

Yours,

--=20
Jean-Marc

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">Le vendredi 18 d=C3=A9cembre 2015 21:17:43 UTC+1, Edward C=
atmur a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><=
p dir=3D"ltr">Ambiguity is *always* desirable, as it is a prerequisite for =
any optimization; there must be multiple possible implementations for there=
 to be any choosing between them.<br></p></blockquote><div><br>That=C2=A0 a=
ffirmation &quot;ambiguity is a prerequisite for any optimization&quot; is =
visibly overreaching.=C2=A0 The as-if rule gives already quite a lot of opp=
ortunity and in fact I wonder how much is there in practice which is not co=
vered by the as-if rule.<br><br>Yours,<br><br>-- <br>Jean-Marc<br></div></d=
iv>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_8_1941904909.1450514956019--
------=_Part_7_851807324.1450514956019--

.

--047d7bd75cb0d4bf2705273d0c7b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 19 Dec 2015 08:49, "Jean-Marc Bourguet" <jm.bourguet@gmail.com> wrote:
>
> Le vendredi 18 d=C3=A9cembre 2015 21:17:43 UTC+1, Edward Catmur a =C3=A9c=
rit :
>>
>>
>> Ambiguity is *always* desirable, as it is a prerequisite for any
optimization; there must be multiple possible implementations for there to
be any choosing between them.
>
>
> That  affirmation "ambiguity is a prerequisite for any optimization" is
visibly overreaching.  The as-if rule gives already quite a lot of
opportunity and in fact I wonder how much is there in practice which is not
covered by the as-if rule.

The as-if rule operates within the ambiguity created by unspecified and
undefined behavior. Most of the time a program will be able to observe
differences in unspecified behavior (for example, inspecting memory
locations or addresses byte wise) that are permitted by the as-if rule.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<p dir=3D"ltr"><br>
On 19 Dec 2015 08:49, &quot;Jean-Marc Bourguet&quot; &lt;<a href=3D"mailto:=
jm.bourguet@gmail.com">jm.bourguet@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Le vendredi 18 d=C3=A9cembre 2015 21:17:43 UTC+1, Edward Catmur a =C3=
=A9crit=C2=A0:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Ambiguity is *always* desirable, as it is a prerequisite for any o=
ptimization; there must be multiple possible implementations for there to b=
e any choosing between them.<br>
&gt;<br>
&gt;<br>
&gt; That=C2=A0 affirmation &quot;ambiguity is a prerequisite for any optim=
ization&quot; is visibly overreaching.=C2=A0 The as-if rule gives already q=
uite a lot of opportunity and in fact I wonder how much is there in practic=
e which is not covered by the as-if rule.</p>
<p dir=3D"ltr">The as-if rule operates within the ambiguity created by unsp=
ecified and undefined behavior. Most of the time a program will be able to =
observe differences in unspecified behavior (for example, inspecting memory=
 locations or addresses byte wise) that are permitted by the as-if rule. </=
p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7bd75cb0d4bf2705273d0c7b--

.

On 12/19/2015 10:40 AM, 'Edward Catmur' via ISO C++ Standard - Future Propo=
sals wrote:
>=20
> On 19 Dec 2015 08:49, "Jean-Marc Bourguet" <jm.bourguet@gmail.com <mailto=
:jm.bourguet@gmail.com>> wrote:
>>
>> Le vendredi 18 d=C3=A9cembre 2015 21:17:43 UTC+1, Edward Catmur a =C3=A9=
crit :
>>>
>>>
>>> Ambiguity is *always* desirable, as it is a prerequisite for any optimi=
zation; there must be multiple possible implementations for there to be any=
 choosing between them.
>>
>>
>> That  affirmation "ambiguity is a prerequisite for any optimization" is =
visibly overreaching.  The as-if rule gives already quite a lot of opportun=
ity and in fact I wonder how much is there in practice which is not covered=
 by the as-if rule.
>=20
> The as-if rule operates within the ambiguity created by unspecified and u=
ndefined behavior. Most of the time a program will be able to observe diffe=
rences in unspecified behavior (for example, inspecting memory locations or=
 addresses byte wise) that are permitted by the as-if rule.

The as-if rule goes farther than exploiting unspecified or undefined behavi=
or.
Rather, it says that only the observable behavior of the abstract
machine is considered when determining implementation conformance (1.9p1).

For example,

int main()
{
  int tmp =3D 0;
  for (int i =3D 0; i < 10; ++i)
    tmp +=3D i;
  volatile int out =3D tmp;
}


I believe this program does not have undefined or unspecified behavior.

Yet, the as-if rule permits
 - generating the code for the loop and computing "tmp" at runtime or
 - simply storing the constant 45 into "out"

You could determine the difference by inspecting the generated machine code=
,
but that's outside of the scope of the C++ standard.

Jens

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

------=_Part_3218_1466614358.1450526951789
Content-Type: multipart/alternative;
 boundary="----=_Part_3219_820016757.1450526951789"

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

Le samedi 19 d=C3=A9cembre 2015 10:40:46 UTC+1, Edward Catmur a =C3=A9crit =
:
>
>
> On 19 Dec 2015 08:49, "Jean-Marc Bourguet" <jm.bo...@gmail.com=20
> <javascript:>> wrote:
> >
> > Le vendredi 18 d=C3=A9cembre 2015 21:17:43 UTC+1, Edward Catmur a =C3=
=A9crit :
> >>
> >>
> >> Ambiguity is *always* desirable, as it is a prerequisite for any=20
> optimization; there must be multiple possible implementations for there t=
o=20
> be any choosing between them.
> >
> >
> > That  affirmation "ambiguity is a prerequisite for any optimization" is=
=20
> visibly overreaching.  The as-if rule gives already quite a lot of=20
> opportunity and in fact I wonder how much is there in practice which is n=
ot=20
> covered by the as-if rule.
>
> The as-if rule operates within the ambiguity created by unspecified and=
=20
> undefined behavior. Most of the time a program will be able to observe=20
> differences in unspecified behavior (for example, inspecting memory=20
> locations or addresses byte wise) that are permitted by the as-if rule.=
=20
>

Do you have a source for that "most of the time"?  Optimizations that break=
=20
assumption about what is legal or not are painfully visible and thus it is=
=20
easy to be aware of them.  Those which have really no observable effect=20
excepted the reduced execution time (or the reduced space taken by the=20
program) are per definition less visible. The proportion of each seems to=
=20
me impossible to assess without a targeted analysis.  What I know is that=
=20
most text-book optimizations (from peep-hole optimization to register=20
allocation) seems to be described at a level where unspecified or undefined=
=20
behaviour is simply not a factor.

(If I wanted to nick pick, I'd argue that "most of the time" optimizations=
=20
are done by the processor, from cache to OOO execution passing by branch=20
prediction).

--=20
Jean-Marc

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

Le samedi 19 d=C3=A9cembre 2015 10:40:46 UTC+1, Edward Catmur a =C3=A9crit=
=C2=A0:<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 19 Dec 2015 08:49, &quot;Jean-Marc Bourguet&quot; &lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"IiH7noEYDgAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">jm.bo...@gmail.com</a>&=
gt; wrote:<br>
&gt;<br>
&gt; Le vendredi 18 d=C3=A9cembre 2015 21:17:43 UTC+1, Edward Catmur a =C3=
=A9crit=C2=A0:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Ambiguity is *always* desirable, as it is a prerequisite for any o=
ptimization; there must be multiple possible implementations for there to b=
e any choosing between them.<br>
&gt;<br>
&gt;<br>
&gt; That=C2=A0 affirmation &quot;ambiguity is a prerequisite for any optim=
ization&quot; is visibly overreaching.=C2=A0 The as-if rule gives already q=
uite a lot of opportunity and in fact I wonder how much is there in practic=
e which is not covered by the as-if rule.</p>
<p dir=3D"ltr">The as-if rule operates within the ambiguity created by unsp=
ecified and undefined behavior. Most of the time a program will be able to =
observe differences in unspecified behavior (for example, inspecting memory=
 locations or addresses byte wise) that are permitted by the as-if rule. </=
p></blockquote><div><br>Do you have a source for that &quot;most of the tim=
e&quot;?=C2=A0 Optimizations that break assumption about what is legal or n=
ot are painfully visible and thus it is easy to be aware of them.=C2=A0 Tho=
se which have really no observable effect excepted the reduced execution ti=
me (or the reduced space taken by the program) are per definition less visi=
ble. The proportion of each seems to me impossible to assess without a targ=
eted analysis.=C2=A0 What I know is that most text-book optimizations (from=
 peep-hole optimization to register allocation) seems to be described at a =
level where unspecified or undefined behaviour is simply not a factor.<br><=
br>(If I wanted to nick pick, I&#39;d argue that &quot;most of the time&quo=
t; optimizations are done by the processor, from cache to OOO execution pas=
sing by branch prediction).<br><br>-- <br>Jean-Marc<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_3219_820016757.1450526951789--
------=_Part_3218_1466614358.1450526951789--

.

--047d7bea43fcb4967a052740bcbc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 19 Dec 2015 12:09, "Jean-Marc Bourguet" <jm.bourguet@gmail.com> wrote:
>
> Le samedi 19 d=C3=A9cembre 2015 10:40:46 UTC+1, Edward Catmur a =C3=A9cri=
t :
>>
>>
>> On 19 Dec 2015 08:49, "Jean-Marc Bourguet" <jm.bo...@gmail.com> wrote:
>> >
>> > Le vendredi 18 d=C3=A9cembre 2015 21:17:43 UTC+1, Edward Catmur a =C3=
=A9crit :
>> >>
>> >>
>> >> Ambiguity is *always* desirable, as it is a prerequisite for any
optimization; there must be multiple possible implementations for there to
be any choosing between them.
>> >
>> >
>> > That  affirmation "ambiguity is a prerequisite for any optimization"
is visibly overreaching.  The as-if rule gives already quite a lot of
opportunity and in fact I wonder how much is there in practice which is not
covered by the as-if rule.
>>
>> The as-if rule operates within the ambiguity created by unspecified and
undefined behavior. Most of the time a program will be able to observe
differences in unspecified behavior (for example, inspecting memory
locations or addresses byte wise) that are permitted by the as-if rule.
>
>
> Do you have a source for that "most of the time"?  Optimizations that
break assumption about what is legal or not are painfully visible and thus
it is easy to be aware of them.  Those which have really no observable
effect excepted the reduced execution time (or the reduced space taken by
the program) are per definition less visible. The proportion of each seems
to me impossible to assess without a targeted analysis.  What I know is
that most text-book optimizations (from peep-hole optimization to register
allocation) seems to be described at a level where unspecified or undefined
behaviour is simply not a factor.
>
> (If I wanted to nick pick, I'd argue that "most of the time"
optimizations are done by the processor, from cache to OOO execution
passing by branch prediction).
>

It's just a guess, I'm afraid. My supporting argument would be that in any
reasonably complex program the stack distance between root and leaf
function calls is highly sensitive to optimization, and this is visible
exploiting only unspecified behavior. When we add undefined behavior a
program can detect even more optimizations, from spawning a thread to
observe memory unsynchronized, to fork and ptrace.

Admittedly I'm not considering optimizations that don't affect the memory
model, but is the as-if rule required to justify those?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<p dir=3D"ltr"><br>
On 19 Dec 2015 12:09, &quot;Jean-Marc Bourguet&quot; &lt;<a href=3D"mailto:=
jm.bourguet@gmail.com">jm.bourguet@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Le samedi 19 d=C3=A9cembre 2015 10:40:46 UTC+1, Edward Catmur a =C3=A9=
crit=C2=A0:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 19 Dec 2015 08:49, &quot;Jean-Marc Bourguet&quot; &lt;<a href=
=3D"mailto:jm.bo...@gmail.com">jm.bo...@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Le vendredi 18 d=C3=A9cembre 2015 21:17:43 UTC+1, Edward Catm=
ur a =C3=A9crit=C2=A0:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Ambiguity is *always* desirable, as it is a prerequisite =
for any optimization; there must be multiple possible implementations for t=
here to be any choosing between them.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; That=C2=A0 affirmation &quot;ambiguity is a prerequisite for =
any optimization&quot; is visibly overreaching.=C2=A0 The as-if rule gives =
already quite a lot of opportunity and in fact I wonder how much is there i=
n practice which is not covered by the as-if rule.<br>
&gt;&gt;<br>
&gt;&gt; The as-if rule operates within the ambiguity created by unspecifie=
d and undefined behavior. Most of the time a program will be able to observ=
e differences in unspecified behavior (for example, inspecting memory locat=
ions or addresses byte wise) that are permitted by the as-if rule.<br>
&gt;<br>
&gt;<br>
&gt; Do you have a source for that &quot;most of the time&quot;?=C2=A0 Opti=
mizations that break assumption about what is legal or not are painfully vi=
sible and thus it is easy to be aware of them.=C2=A0 Those which have reall=
y no observable effect excepted the reduced execution time (or the reduced =
space taken by the program) are per definition less visible. The proportion=
 of each seems to me impossible to assess without a targeted analysis.=C2=
=A0 What I know is that most text-book optimizations (from peep-hole optimi=
zation to register allocation) seems to be described at a level where unspe=
cified or undefined behaviour is simply not a factor.<br>
&gt;<br>
&gt; (If I wanted to nick pick, I&#39;d argue that &quot;most of the time&q=
uot; optimizations are done by the processor, from cache to OOO execution p=
assing by branch prediction).<br>
&gt;</p>
<p dir=3D"ltr">It&#39;s just a guess, I&#39;m afraid. My supporting argumen=
t would be that in any reasonably complex program the stack distance betwee=
n root and leaf function calls is highly sensitive to optimization, and thi=
s is visible exploiting only unspecified behavior. When we add undefined be=
havior a program can detect even more optimizations, from spawning a thread=
 to observe memory unsynchronized, to fork and ptrace.</p>
<p dir=3D"ltr">Admittedly I&#39;m not considering optimizations that don&#3=
9;t affect the memory model, but is the as-if rule required to justify thos=
e? <br>
</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7bea43fcb4967a052740bcbc--

.

------=_Part_594_1382814321.1450683049831
Content-Type: multipart/alternative;
 boundary="----=_Part_595_1033145854.1450683049832"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8818=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8A=E5=8D=882:32:34=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Dec 16, 2015 at 5:59 PM, 'Edward Catmur' via ISO C++ Standard -=
=20
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> ... except for types in declarators, and numbers, obviously.
>>>
>>
> I don't understand what this means.
>
> Also, I assume you would retain the short-circuiting behavior of the=20
>>> logical and ternary conditional operators.
>>>
>>
> Of course.  I have previously proposed, informally, that it should be=20
> possible to annotate a function parameter declaration something like this=
, void=20
> f([] int i), such that at the call site the argument expression would be=
=20
> packaged into a (special type of) lambda which would only be evaluated=20
> inside f when called for.  This would allow user code to create its own=
=20
> short-circuit forms, including finally the ability to properly overload=
=20
> operator&& and operator|| while preserving short-circuit semantics.=20
>  (These lambdas need to be special because every ordinary lambda has a=20
> different type, which would force f to become a template.)
>
The special non-strict semantics of some logical operations ("and" and=20
"or") may sound wrong to novice. It breaks the symmetry, which is held by=
=20
the mathematical definition of these operations. For a language with side=
=20
effects, this is not trivial. So they will known actually '&&' is not=20
"logical and" and '||' is not "logical or" in this sense. The result is,=20
these operations violate the "expectation", but they are still accepted.=20
You may think it is natural, just because it *is *there. That's *you*. (I=
=20
don't care them too much because functions work around them well.)

How to provide non-strict semantics in general is out of the topic. But I=
=20
am sure it would not be easier to settle them down after you hard-code the=
=20
evaluation rules. (The language has provided similar semantics within other=
=20
constructs, i.e. conditional expressions and "if" statement. These rules=20
are difficult to merge.)

And don't forget that the arguments to an inline lambda will be evaluated=
=20
>>> before the body of the lambda function is entered, so those aren't stri=
ct=20
>>> left-to-right either.
>>>
>>
> But a function definition is never evaluated; a function is executed only=
=20
> as part of a call expression.  A braced sequence of code is not an=20
> expression.
>
> A lambda expression is not a function definition. It is an expression. Th=
e=20
order is irrelevant because there are nothing to be unsequenced within the=
=20
evaluation of lambda expression itself: no side effects, no values of=20
scalar types computed depending on other evaluations. This is still, by=20
definition, one "evaluation".
=20

> A few more points: that code depending on evaluation order is (generally)=
=20
>> unclear and overcomplicated and should not be encouraged; and that a=20
>> high-level language should empower the user to express *what* the progra=
m=20
>> should do, not *how* it should do it, with unspecified evaluation order=
=20
>> tending towards the former and strict left-to-right evaluation order=20
>> encouraging the latter, even when it is not intended.
>>
>
> No, this is exactly backwards.  The reason such code appears unclear and=
=20
> overcomplicated is because the language has failed to define what the cod=
e=20
> does.  You are correct that code should specify what the program should d=
o;=20
> language rules that refuse to define what code means get in the way betwe=
en=20
> what the program expresses and what the program does.
>
Wrong. Because expressing "no guarantee of order" is a valid meaning. Why=
=20
it is valuable, or whether it should be in the language or not, are other=
=20
topics.

The only reason for thinking that leaving order of evaluation unspecified=
=20
> is good is because of Stockholm Syndrome - it has been this way for so lo=
ng=20
> that people have found reasons for believing this way is right rather tha=
n=20
> fighting against it.
>
Again, that's *you*. You, as well as some others, may have no need to=20
express unsequenced evaluations, but there are people who have it with=20
quite valid reasons to make the feature "portable". On the contrary, you=20
are trying to abduct others' requirements to the language based on your=20
need, or the need you imagine the users of the language should have. Who=20
are the victims of Stockholm Syndrome?
=20

> But leaving the order of evaluation of f(a(), b()) unspecified should=20
> feel as horrifying as if the language were to say that a(); b(); had=20
> unspecified order.
> =20
>
Why to fold them together? They should be different at first glance. The=20
semicolon ";" is just dedicated to the ("left-to-right") order in C and=20
C++, without any other semantically usage if not taking "no-op" into=20
account. (Though the syntax matters in other way.)

If you were talking about the comma operator, this would be plausible,=20
since overloaded operator, is inconsistent with built-in one. But you were=
=20
not.
=20

> With SMP systems now the default at most scales, the concept of=20
>> indeterminate sequencing of side effects should be familiar to most user=
s.=20
>> Indeed, with transactional memory becoming available on commodity hardwa=
re=20
>> it is surely only a matter of time before speculative multithreading mov=
es=20
>> from academia to becoming a standard compiler technique; the more that=
=20
>> C++'s evaluation order is "nailed down", the less it will be amenable to=
=20
>> these optimization techniques.
>>
>
> The problem is that a programming language is meant to express=20
> instructions to a machine.
>
Yes, it is a problem, if it is only expected to do so. As a high level=20
language, it should be more or less able to directly (i.e. without comments=
=20
encoded in natural languages) express the intention of the author of the=20
code, rather than be restricted on such concrete implementation details.

In fact you cannot always find the machine code generated by a C++ compiler=
=20
easily. They may have been optimized away totally. Thus there exists C++=20
code which does not express instructions to a machine at all.
=20

> Letting the language be ambiguous leads to errors, not efficiencies.=20
>
Not all ambiguity is unintentional.
=20

> The compiler does not know whether the ambiguity you have placed into you=
r=20
> code is deliberate or wrong, and chooses to think it's the former.  If=20
> there are circumstances where ambiguous order is desirable, the programmi=
ng=20
> language should provide a means for the programmer to explicitly say so.=
=20
>  (And no, f((a(), 0), (b(), 0)) is not the way.)=20
>

True, for a language with too many evaluation rules.
=20

>
>> The problem is that this is an irrevocable decision; if evaluation order=
=20
>> were to be made strict, it would be very difficult later to relax it. A=
=20
>> similar objection holds in the small; right now, it is easy to guarantee=
 a=20
>> particular evaluation order of a piece of code, as you have covered abov=
e;=20
>> however under the proposals there would be no way explicitly to relax th=
e=20
>> evaluation order among a collection of subexpressions.
>>
>
> I would be fine with there being no such way, or with having some piece o=
f=20
> standout syntax to indicate it.  This is how the (implementation-dependen=
t)=20
> branch-prediction syntax works; you sprinkle your code with=20
> __builtin_expect when you want to tell the compiler how you think a=20
> branch will go.
>
>
I would not be fine if there is no such way. But I have no idea what syntax=
=20
should be chosen. You can propose it. But no __builtin_expect please, it is=
=20
only available in dialects. There is one more difference: __builtin_expect =
is=20
not needed to be standardized because it does not change the semantics=20
properties the abstract model and thus it is covered by the as-if rules.=20
The order of evaluations is not.

Anyway, simply reducing the expressiveness of the language without very=20
strong reasons or replacements, are not acceptable in general.



--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8818=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=94 UTC+8=E4=B8=8A=E5=8D=882:32:34=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">On Wed, Dec 16, 2015 at 5:59 PM, &#39;Edward Ca=
tmur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ec8FnF2YDQA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr..=
..@isocpp.org</a>&gt;</span> wrote:<br><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><div class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">... e=
xcept for types in declarators, and numbers, obviously.</div></blockquote><=
/span></div></div></div></blockquote><div><br>I don&#39;t understand what t=
his means.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><span><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"> Also, I assume yo=
u would retain the short-circuiting behavior of the logical and ternary con=
ditional operators.</div></blockquote></span></div></div></div></blockquote=
><div><br>Of course.=C2=A0 I have previously proposed, informally, that it =
should be possible to annotate a function parameter declaration something l=
ike this, <font face=3D"monospace, monospace">void f([] int i)</font>, such=
 that at the call site the argument expression would be packaged into a (sp=
ecial type of) lambda which would only be evaluated inside <font face=3D"mo=
nospace, monospace">f</font> when called for.=C2=A0 This would allow user c=
ode to create its own short-circuit forms, including finally the ability to=
 properly overload <font face=3D"monospace, monospace">operator&amp;&amp;</=
font> and <font face=3D"monospace, monospace">operator||</font> while prese=
rving short-circuit semantics. =C2=A0(These lambdas need to be special beca=
use every ordinary lambda has a different type, which would force=C2=A0<spa=
n style=3D"font-family:monospace,monospace">f</span>=C2=A0to become a templ=
ate.)<br></div></div></div></div></blockquote><div>The special non-strict s=
emantics of some logical operations (&quot;and&quot; and &quot;or&quot;) ma=
y sound wrong to novice. It breaks the symmetry, which is held by the mathe=
matical definition of these operations. For a language with side effects, t=
his is not trivial. So they will known actually &#39;&amp;&amp;&#39; is not=
 &quot;logical and&quot; and &#39;||&#39; is not &quot;logical or&quot; in =
this sense. The result is, these operations violate the &quot;expectation&q=
uot;, but they are still accepted. You may think it is natural, just becaus=
e it <i>is </i>there. That&#39;s <i>you</i>. (I don&#39;t care them too muc=
h because functions work around them well.)<br><br>How to provide non-stric=
t semantics in general is out of the topic. But I am sure it would not be e=
asier to settle them down after you hard-code the evaluation rules. (The la=
nguage has provided similar semantics within other constructs,=20
i.e. conditional expressions and &quot;if&quot; statement. These rules are =
difficult to merge.)<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 class=3D"gmail_quote"><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"><span><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div d=
ir=3D"ltr"> And don&#39;t forget that the arguments to an inline lambda wil=
l be evaluated before the body of the lambda function is entered, so those =
aren&#39;t strict left-to-right either.<br></div></blockquote></span></div>=
</div></div></blockquote><div><br>But a function definition is never evalua=
ted; a function is executed only as part of a call expression.=C2=A0 A brac=
ed sequence of code is not an expression.<br><br></div></div></div></div></=
blockquote><div>A lambda expression is not a function definition. It is an =
expression.=20
The order is irrelevant because there are nothing to be unsequenced=20
within the evaluation of lambda expression itself: no side effects, no=20
values of scalar types computed depending on other evaluations. This is=20
still, by definition, one &quot;evaluation&quot;.<br>=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"><div><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"><div dir=3D"ltr"><div><div class=3D"gmail_quote">=
<div> A few more points: that code depending on evaluation order is (genera=
lly) unclear and overcomplicated and should not be encouraged; and that a h=
igh-level language should empower the user to express *what* the program sh=
ould do, not *how* it should do it, with unspecified evaluation order tendi=
ng towards the former and strict left-to-right evaluation order encouraging=
 the latter, even when it is not intended.</div></div></div></div></blockqu=
ote><div><br>No, this is exactly backwards.=C2=A0 The reason such code appe=
ars unclear and overcomplicated is because the language has failed to defin=
e what the code does.=C2=A0 You are correct that code should specify what t=
he program should do; language rules that refuse to define what code means =
get in the way between what the program expresses and what the program does=
..</div></div></div></div></blockquote><div>Wrong. Because expressing &quot;=
no guarantee of order&quot; is a valid meaning. Why it is valuable, or whet=
her it should be in the language or not, are other topics.<br><br></div><bl=
ockquote 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>The only reason for thinking that leaving order of ev=
aluation unspecified is good is because of Stockholm Syndrome - it has been=
 this way for so long that people have found reasons for believing this way=
 is right rather than fighting against it.</div></div></div></div></blockqu=
ote><div>Again, that&#39;s <i>you</i>. You, as well as some others, may hav=
e no need to express unsequenced evaluations, but there are people who have=
 it with quite valid reasons to make the feature &quot;portable&quot;. On t=
he contrary, you are trying to abduct others&#39; requirements to the langu=
age based on your need, or the need you imagine the users of the language s=
hould have. Who are the victims of Stockholm Syndrome?<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>But leaving the order of evaluation of <font face=3D=
"monospace, monospace">f(a(), b())</font> unspecified should feel as horrif=
ying as if the language were to say that <font face=3D"monospace, monospace=
">a(); b();</font> had unspecified order.<br>=C2=A0</div></div></div></div>=
</blockquote><div>Why to fold them together? They should be different at fi=
rst glance. The semicolon &quot;;&quot; is just dedicated to the (&quot;lef=
t-to-right&quot;) order in C and C++, without any other semantically usage =
if not taking &quot;no-op&quot; into account. (Though the syntax matters in=
 other way.)<br><br>If you were talking about the comma operator, this woul=
d be plausible, since overloaded operator, is inconsistent with built-in on=
e. But you were not.<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><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>With SMP systems now=
 the default at most scales, the concept of indeterminate sequencing of sid=
e effects should be familiar to most users. Indeed, with transactional memo=
ry becoming available on commodity hardware it is surely only a matter of t=
ime before speculative multithreading moves from academia to becoming a sta=
ndard compiler technique; the more that C++&#39;s evaluation order is &quot=
;nailed down&quot;, the less it will be amenable to these optimization tech=
niques.</div></div></div></div></blockquote><div><br>The problem is that a =
programming language is meant to express instructions to a machine.</div></=
div></div></div></blockquote><div>Yes, it is a problem, if it is only expec=
ted to do so. As a high level language, it should be more or less able to d=
irectly (i.e. without comments encoded in natural languages) express the in=
tention of the author of the code, rather than be restricted on such concre=
te implementation details.<br><br>In fact you cannot always find the machin=
e code generated by a C++ compiler easily. They may have been optimized awa=
y totally. Thus there exists C++ code which does not express instructions t=
o a machine at all.<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>Letting the lan=
guage be ambiguous leads to errors, not efficiencies.=C2=A0</div></div></di=
v></div></blockquote><div>Not all ambiguity is unintentional.<br>=C2=A0</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>The compiler does not know whether the ambiguity =
you have placed into your code is deliberate or wrong, and chooses to think=
 it&#39;s the former.=C2=A0 If there are circumstances where ambiguous orde=
r is desirable, the programming language should provide a means for the pro=
grammer to explicitly say so. =C2=A0(And no, <font face=3D"monospace, monos=
pace">f((a(), 0), (b(), 0))</font> is not the way.) <br></div></div></div><=
/div></blockquote><div><br>True, for a language with too many evaluation ru=
les.<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=
ir=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,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote"><div><br></div><div>The problem is that t=
his is an irrevocable decision; if evaluation order were to be made strict,=
 it would be very difficult later to relax it. A similar objection holds in=
 the small; right now, it is easy to guarantee a particular evaluation orde=
r of a piece of code, as you have covered above; however under the proposal=
s there would be no way explicitly to relax the evaluation order among a co=
llection of subexpressions.</div></div></div></div></blockquote><div><br>I =
would be fine with there being no such way, or with having some piece of st=
andout syntax to indicate it.=C2=A0 This is how the (implementation-depende=
nt) branch-prediction syntax works; you sprinkle your code with=C2=A0<span =
style=3D"color:rgb(0,0,0);white-space:inherit;font-size:13px;background-col=
or:rgb(255,255,255)"><font face=3D"monospace, monospace">__builtin_expect</=
font></span><span style=3D"color:rgb(0,0,0);white-space:inherit;font-size:1=
3px;background-color:rgb(255,255,255)"><font face=3D"arial, helvetica, sans=
-serif">=C2=A0when you want to tell the compiler how you think a branch wil=
l go.</font></span></div></div><br></div></div></blockquote><div><br>I woul=
d not be fine if there is no such way. But I have no idea what syntax shoul=
d be chosen. You can propose it. But no <span style=3D"color:rgb(0,0,0);whi=
te-space:inherit;font-size:13px;background-color:rgb(255,255,255)"><font fa=
ce=3D"monospace, monospace">__builtin_expect </font></span>please, it is on=
ly available in dialects. There is one more difference: <span style=3D"colo=
r:rgb(0,0,0);white-space:inherit;font-size:13px;background-color:rgb(255,25=
5,255)"><font face=3D"monospace, monospace">__builtin_expect </font></span>=
is not needed to be standardized because it does not change the semantics p=
roperties the abstract model and thus it is covered by the as-if rules. The=
 order of evaluations is not.<br><br>Anyway, simply reducing the expressive=
ness of the language without very strong reasons or replacements, are not a=
cceptable in general.<br><br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_595_1033145854.1450683049832--
------=_Part_594_1382814321.1450683049831--

.

------=_Part_684_308009264.1450689516223
Content-Type: multipart/alternative;
 boundary="----=_Part_685_70421177.1450689516223"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UT=
C+8=E4=B8=8A=E5=8D=884:17:43=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
> > The problem is that a programming language is meant to express=20
> instructions to a machine.  Letting the language be ambiguous leads to=20
> errors, not efficiencies.  The compiler does not know whether the ambigui=
ty=20
> you have placed into your code is deliberate or wrong, and chooses to thi=
nk=20
> it's the former.  If there are circumstances where ambiguous order is=20
> desirable, the programming language should provide a means for the=20
> programmer to explicitly say so.  (And no, f((a(), 0), (b(), 0)) is not t=
he=20
> way.)
>
> No, programming languages express a computation, which may be an=20
> algorithm, a function, a query or so on, and allow the compiler to choose=
=20
> among appropriate sequences of machine instructions. If you want to write=
=20
> machine instructions, program in assembler. Or Forth.=20
>
> Ambiguity is *always* desirable, as it is a prerequisite for any=20
> optimization; there must be multiple possible implementations for there t=
o=20
> be any choosing between them.
>

I don't think the expressing unsequenced evaluations is ambiguity. The=20
property of unsequenced evaluation can be just distinguishable to any other=
=20
order of evaluations in a metalanguage of formal semantics. So it is=20
unambiguous in nature. What may cause you think it is ambiguity is the=20
behavior of the implementation, where something has eventually to figure=20
out the order in (macro) physics unless it is not predictable by design=20
("undefined"). However this is different to the semantics. Treating the=20
implementation details as "disambiguition" should also not be desired.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=85=AD UTC+8=E4=B8=8A=E5=8D=884:17:43=EF=BC=8CEdward Catmur=E5=86=99=E9=81=
=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><p dir=3D"ltr"=
>
&gt; The problem is that a programming language is meant to express instruc=
tions to a machine.=C2=A0 Letting the language be ambiguous leads to errors=
, not efficiencies.=C2=A0 The compiler does not know whether the ambiguity =
you have placed into your code is deliberate or wrong, and chooses to think=
 it&#39;s the former.=C2=A0 If there are circumstances where ambiguous orde=
r is desirable, the programming language should provide a means for the pro=
grammer to explicitly say so. =C2=A0(And no, f((a(), 0), (b(), 0)) is not t=
he way.)</p>
<p dir=3D"ltr">No, programming languages express a computation, which may b=
e an algorithm, a function, a query or so on, and allow the compiler to cho=
ose among appropriate sequences of machine instructions. If you want to wri=
te machine instructions, program in assembler. Or Forth. </p>
<p dir=3D"ltr">Ambiguity is *always* desirable, as it is a prerequisite for=
 any optimization; there must be multiple possible implementations for ther=
e to be any choosing between them.<br></p></blockquote><div><br>I don&#39;t=
 think the expressing unsequenced evaluations is ambiguity. The property of=
 unsequenced evaluation can be just distinguishable to any other order of e=
valuations in a metalanguage of formal semantics. So it is unambiguous in n=
ature. What may cause you think it is ambiguity is the behavior of the impl=
ementation, where something has eventually to figure out the order  in (mac=
ro) physics unless it is not predictable by design (&quot;undefined&quot;).=
 However this is different to the semantics. Treating the implementation de=
tails as &quot;disambiguition&quot; should also not be desired.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_685_70421177.1450689516223--
------=_Part_684_308009264.1450689516223--

.

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

The wrong-thinking around defined order of evaluation proceeds as it always
does.

The number "one hundred and thirty-seven" is written as 137.  How is this
not left-to-right?  In non-place notation, such as Roman numerals, the
number is written as CXXXVII, also left-to-right.  We are about to exit
year 2015, which everyone pronounces as "twenty-fifteen", reading it left
to right.  The declarator syntax is bad because it's not read left to
right.  Ada gets this right (as usual) by having declarations read
naturally: type PP is access Positive; type APP is array(1..10) of PP;.

Optimization is the choosing of one of a set of possible translations of a
code written in one programming language into another in a way that
expresses the intent of the source and satisfies some other criteria.  It
is not necessary for the intent of the source to be ambiguous,

If the intent of a piece of code is ambiguous, the system which executes it
has no way of knowing if the ambiguity is intentional, because all possible
interpretations are acceptable to the creator, or accidental, because the
programmer believed that some particular interpretation was the only
possible one.  If the interpretation chosen by the system matches the
expectation of the programmer, the ambiguity may go undetected for a long
time, until the system changes and picks a different interpretation.  If it
is believed that a programming language should be able to express ambiguity
of intent, then that ambiguity should be clearly spelled out so that both
programmer and execution system can agree that the ambiguity is wanted.

That fact that coding guidelines warn against depending on order of
evaluation is a sign that the authors of the guidelines believe that even
the appearance of ambiguity leads to problems.  Codifying actual ambiguity
into the language can only make problems worse - in the former
specified-but-suspicious case, the code may be obscure but both programmer
and execution system will permanently agree on what it means.  In the
latter suspicious-and-unspecified case, the programmer will iterate until
the current execution system appears to match the intent of the code, and
then the other possible legal intents will go unnoticed until some future
time, and havoc ensues.

There is abundant evidence from decades of discussion that programmers,
even expert ones, do not understand the rules controlling order of
evaluation in C and C++.  That alone is sufficient reason to fix the rules.

As for the non-strict semantics of && and ||, Ada had the design right (as
usual).  In Ada, if you want short-circuiting, you say C1 and then C2 and C=
1
or else C2.  If you don't, you say C1 and C2 and C1 or C2.  In Ada, you
can't overload the short-circuit forms, so there isn't the ambiguity
between built-in and overloaded operators.

On Mon, Dec 21, 2015 at 4:18 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:

>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD =
UTC+8=E4=B8=8A=E5=8D=884:17:43=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>>
>> > The problem is that a programming language is meant to express
>> instructions to a machine.  Letting the language be ambiguous leads to
>> errors, not efficiencies.  The compiler does not know whether the ambigu=
ity
>> you have placed into your code is deliberate or wrong, and chooses to th=
ink
>> it's the former.  If there are circumstances where ambiguous order is
>> desirable, the programming language should provide a means for the
>> programmer to explicitly say so.  (And no, f((a(), 0), (b(), 0)) is not =
the
>> way.)
>>
>> No, programming languages express a computation, which may be an
>> algorithm, a function, a query or so on, and allow the compiler to choos=
e
>> among appropriate sequences of machine instructions. If you want to writ=
e
>> machine instructions, program in assembler. Or Forth.
>>
>> Ambiguity is *always* desirable, as it is a prerequisite for any
>> optimization; there must be multiple possible implementations for there =
to
>> be any choosing between them.
>>
>
> I don't think the expressing unsequenced evaluations is ambiguity. The
> property of unsequenced evaluation can be just distinguishable to any oth=
er
> order of evaluations in a metalanguage of formal semantics. So it is
> unambiguous in nature. What may cause you think it is ambiguity is the
> behavior of the implementation, where something has eventually to figure
> out the order in (macro) physics unless it is not predictable by design
> ("undefined"). However this is different to the semantics. Treating the
> implementation details as "disambiguition" should also not be desired.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">The wrong-thinking around defined order of evaluation proc=
eeds as it always does.<br><br>The number &quot;one hundred and thirty-seve=
n&quot; is written as 137.=C2=A0 How is this not left-to-right?=C2=A0 In no=
n-place notation, such as Roman numerals, the number is written as CXXXVII,=
 also left-to-right.=C2=A0 We are about to exit year 2015, which everyone p=
ronounces as &quot;twenty-fifteen&quot;, reading it left to right.=C2=A0 Th=
e declarator syntax is bad because it&#39;s not read left to right.=C2=A0 A=
da gets this right (as usual) by having declarations read naturally: <font =
face=3D"monospace, monospace">type PP is access Positive; type APP is array=
(1..10) of PP;</font>.<br><br>Optimization is the choosing of one of a set =
of possible translations of a code written in one programming language into=
 another in a way that expresses the intent of the source and satisfies som=
e other criteria.=C2=A0 It is not necessary for the intent of the source to=
 be ambiguous,<br><br>If the intent of a piece of code is ambiguous, the sy=
stem which executes it has no way of knowing if the ambiguity is intentiona=
l, because all possible interpretations are acceptable to the creator, or a=
ccidental, because the programmer believed that some particular interpretat=
ion was the only possible one.=C2=A0 If the interpretation chosen by the sy=
stem matches the expectation of the programmer, the ambiguity may go undete=
cted for a long time, until the system changes and picks a different interp=
retation.=C2=A0 If it is believed that a programming language should be abl=
e to express ambiguity of intent, then that ambiguity should be clearly spe=
lled out so that both programmer and execution system can agree that the am=
biguity is wanted.<br><br>That fact that coding guidelines warn against dep=
ending on order of evaluation is a sign that the authors of the guidelines =
believe that even the appearance of ambiguity leads to problems.=C2=A0 Codi=
fying actual ambiguity into the language can only make problems worse - in =
the former specified-but-suspicious case, the code may be obscure but both =
programmer and execution system will permanently agree on what it means.=C2=
=A0 In the latter suspicious-and-unspecified case, the programmer will iter=
ate until the current execution system appears to match the intent of the c=
ode, and then the other possible legal intents will go unnoticed until some=
 future time, and havoc ensues.<br><br>There is abundant evidence from deca=
des of discussion that programmers, even expert ones, do not understand the=
 rules controlling order of evaluation in C and C++.=C2=A0 That alone is su=
fficient reason to fix the rules.<br><br>As for the non-strict semantics of=
 &amp;&amp; and ||, Ada had the design right (as usual).=C2=A0 In Ada, if y=
ou want short-circuiting, you say <font face=3D"monospace, monospace">C1 an=
d then C2</font> and <font face=3D"monospace, monospace">C1 or else C2</fon=
t>.=C2=A0 If you don&#39;t, you say <font face=3D"monospace, monospace">C1 =
and C2</font> and <font face=3D"monospace, monospace">C1 or C2</font>.=C2=
=A0 In Ada, you can&#39;t overload the short-circuit forms, so there isn&#3=
9;t the ambiguity between built-in and overloaded operators.</div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Dec 21, 2015 at 4:=
18 AM, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmai=
l.com" target=3D"_blank">frankhb1989@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8819=E6=
=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=884:17:43=EF=BC=8CEd=
ward Catmur=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 soli=
d;padding-left:1ex"><br><p dir=3D"ltr">
&gt; The problem is that a programming language is meant to express instruc=
tions to a machine.=C2=A0 Letting the language be ambiguous leads to errors=
, not efficiencies.=C2=A0 The compiler does not know whether the ambiguity =
you have placed into your code is deliberate or wrong, and chooses to think=
 it&#39;s the former.=C2=A0 If there are circumstances where ambiguous orde=
r is desirable, the programming language should provide a means for the pro=
grammer to explicitly say so. =C2=A0(And no, f((a(), 0), (b(), 0)) is not t=
he way.)</p>
<p dir=3D"ltr">No, programming languages express a computation, which may b=
e an algorithm, a function, a query or so on, and allow the compiler to cho=
ose among appropriate sequences of machine instructions. If you want to wri=
te machine instructions, program in assembler. Or Forth. </p>
<p dir=3D"ltr">Ambiguity is *always* desirable, as it is a prerequisite for=
 any optimization; there must be multiple possible implementations for ther=
e to be any choosing between them.<br></p></blockquote></span><div><br>I do=
n&#39;t think the expressing unsequenced evaluations is ambiguity. The prop=
erty of unsequenced evaluation can be just distinguishable to any other ord=
er of evaluations in a metalanguage of formal semantics. So it is unambiguo=
us in nature. What may cause you think it is ambiguity is the behavior of t=
he implementation, where something has eventually to figure out the order  =
in (macro) physics unless it is not predictable by design (&quot;undefined&=
quot;). However this is different to the semantics. Treating the implementa=
tion details as &quot;disambiguition&quot; should also not be desired.<br><=
/div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a114267f04d904b05276b5ac3--

.

------=_Part_3501_907115680.1450723283902
Content-Type: multipart/alternative;
 boundary="----=_Part_3502_1229386906.1450723283902"

------=_Part_3502_1229386906.1450723283902
Content-Type: text/plain; charset=UTF-8



On Monday, December 21, 2015 at 8:30:49 AM UTC+1, FrankHB1989 wrote:
>
>
> The only reason for thinking that leaving order of evaluation unspecified
>> is good is because of Stockholm Syndrome - it has been this way for so long
>> that people have found reasons for believing this way is right rather than
>> fighting against it.
>>
> Again, that's *you*. You, as well as some others, may have no need to
> express unsequenced evaluations, but there are people who have it with
> quite valid reasons to make the feature "portable". On the contrary, you
> are trying to abduct others' requirements to the language based on your
> need, or the need you imagine the users of the language should have. Who
> are the victims of Stockholm Syndrome?
>

Why you or others need express unsequenced evaluation? What it will give
you and what is difference compared to using sequenced call? In function
arguments passing it can simplify pushing values on stack, but here you
don't use it, then what is goal?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Monday, December 21, 2015 at 8:30:49 AM UTC+1, FrankHB1989 wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><br><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"><div>The on=
ly reason for thinking that leaving order of evaluation unspecified is good=
 is because of Stockholm Syndrome - it has been this way for so long that p=
eople have found reasons for believing this way is right rather than fighti=
ng against it.</div></div></div></div></blockquote><div>Again, that&#39;s <=
i>you</i>. You, as well as some others, may have no need to express unseque=
nced evaluations, but there are people who have it with quite valid reasons=
 to make the feature &quot;portable&quot;. On the contrary, you are trying =
to abduct others&#39; requirements to the language based on your need, or t=
he need you imagine the users of the language should have. Who are the vict=
ims of Stockholm Syndrome?</div></blockquote><div><br>Why you or others nee=
d express unsequenced evaluation? What it will give you and what is differe=
nce compared to using sequenced call? In function arguments passing it can =
simplify pushing values on stack, but here you don&#39;t use it, then what =
is goal?<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_3502_1229386906.1450723283902--
------=_Part_3501_907115680.1450723283902--

.

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

As well, modern architectures pass function arguments in registers, so
pushing on the stack isn't really an issue.

On Mon, Dec 21, 2015 at 1:41 PM, <inkwizytoryankes@gmail.com> wrote:

>
>
> On Monday, December 21, 2015 at 8:30:49 AM UTC+1, FrankHB1989 wrote:
>>
>>
>> The only reason for thinking that leaving order of evaluation unspecified
>>> is good is because of Stockholm Syndrome - it has been this way for so long
>>> that people have found reasons for believing this way is right rather than
>>> fighting against it.
>>>
>> Again, that's *you*. You, as well as some others, may have no need to
>> express unsequenced evaluations, but there are people who have it with
>> quite valid reasons to make the feature "portable". On the contrary, you
>> are trying to abduct others' requirements to the language based on your
>> need, or the need you imagine the users of the language should have. Who
>> are the victims of Stockholm Syndrome?
>>
>
> Why you or others need express unsequenced evaluation? What it will give
> you and what is difference compared to using sequenced call? In function
> arguments passing it can simplify pushing values on stack, but here you
> don't use it, then what is goal?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">As well, modern architectures pass function arguments in r=
egisters, so pushing on the stack isn&#39;t really an issue.</div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Dec 21, 2015 at 1:=
41 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwizytoryankes@gmail.com"=
 target=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D""><br><br>On Monday, December 21,=
 2015 at 8:30:49 AM UTC+1, FrankHB1989 wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><br><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>The only reason for thinking that leaving =
order of evaluation unspecified is good is because of Stockholm Syndrome - =
it has been this way for so long that people have found reasons for believi=
ng this way is right rather than fighting against it.</div></div></div></di=
v></blockquote><div>Again, that&#39;s <i>you</i>. You, as well as some othe=
rs, may have no need to express unsequenced evaluations, but there are peop=
le who have it with quite valid reasons to make the feature &quot;portable&=
quot;. On the contrary, you are trying to abduct others&#39; requirements t=
o the language based on your need, or the need you imagine the users of the=
 language should have. Who are the victims of Stockholm Syndrome?</div></bl=
ockquote></span><div><br>Why you or others need express unsequenced evaluat=
ion? What it will give you and what is difference compared to using sequenc=
ed call? In function arguments passing it can simplify pushing values on st=
ack, but here you don&#39;t use it, then what is goal?<br></div><div class=
=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113dad64afc8f805276e489b--

.

------=_Part_5371_1105014243.1450743818469
Content-Type: multipart/alternative;
 boundary="----=_Part_5372_1572275398.1450743818470"

------=_Part_5372_1572275398.1450743818470
Content-Type: text/plain; charset=UTF-8



On Monday, December 21, 2015 at 10:25:06 PM UTC+2, Hyman Rosen wrote:
>
> As well, modern architectures pass function arguments in registers, so
> pushing on the stack isn't really an issue.
>
> On Mon, Dec 21, 2015 at 1:41 PM, <inkwizyt...@gmail.com <javascript:>>
> wrote:
>
>>
>>
>> On Monday, December 21, 2015 at 8:30:49 AM UTC+1, FrankHB1989 wrote:
>>>
>>>
>>> The only reason for thinking that leaving order of evaluation
>>>> unspecified is good is because of Stockholm Syndrome - it has been this way
>>>> for so long that people have found reasons for believing this way is right
>>>> rather than fighting against it.
>>>>
>>> Again, that's *you*. You, as well as some others, may have no need to
>>> express unsequenced evaluations, but there are people who have it with
>>> quite valid reasons to make the feature "portable". On the contrary, you
>>> are trying to abduct others' requirements to the language based on your
>>> need, or the need you imagine the users of the language should have. Who
>>> are the victims of Stockholm Syndrome?
>>>
>>
>> Why you or others need express unsequenced evaluation? What it will give
>> you and what is difference compared to using sequenced call? In function
>> arguments passing it can simplify pushing values on stack, but here you
>> don't use it, then what is goal?
>>
>> --
>>
>> The difference is that we don't want to write fortran style to have
optimized expressions. Consider:
         int extfunc(const int & param);

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Monday, December 21, 2015 at 10:25:06 PM UTC+2, Hyman Rosen wrot=
e:<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">As well, mo=
dern architectures pass function arguments in registers, so pushing on the =
stack isn&#39;t really an issue.</div><div><br><div class=3D"gmail_quote">O=
n Mon, Dec 21, 2015 at 1:41 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"u0cx69PYDgAJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">inkwizyt...@gmail.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"><span><br><br>On Mon=
day, December 21, 2015 at 8:30:49 AM UTC+1, FrankHB1989 wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The only reason for think=
ing that leaving order of evaluation unspecified is good is because of Stoc=
kholm Syndrome - it has been this way for so long that people have found re=
asons for believing this way is right rather than fighting against it.</div=
></div></div></div></blockquote><div>Again, that&#39;s <i>you</i>. You, as =
well as some others, may have no need to express unsequenced evaluations, b=
ut there are people who have it with quite valid reasons to make the featur=
e &quot;portable&quot;. On the contrary, you are trying to abduct others&#3=
9; requirements to the language based on your need, or the need you imagine=
 the users of the language should have. Who are the victims of Stockholm Sy=
ndrome?</div></blockquote></span><div><br>Why you or others need express un=
sequenced evaluation? What it will give you and what is difference compared=
 to using sequenced call? In function arguments passing it can simplify pus=
hing values on stack, but here you don&#39;t use it, then what is goal?<br>=
</div><div><div>

<p></p>

-- <br><br></div></div></blockquote></div></div></blockquote><div>The diffe=
rence is that we don&#39;t want to write fortran style to have optimized ex=
pressions. Consider:<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int extfunc(const=
 int &amp; param);<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_5372_1572275398.1450743818470--
------=_Part_5371_1105014243.1450743818469--

.

--089e0111be1cc2d0c505278191ad
Content-Type: text/plain; charset=UTF-8

On Mon, Dec 21, 2015 at 4:54 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> Optimization is the choosing of one of a set of possible translations of a
> code written in one programming language into another in a way that
> expresses the intent of the source and satisfies some other criteria.  It
> is not necessary for the intent of the source to be ambiguous,
>

In the way you're using it, "ambiguous" is a value judgement; you're using
it to indicate the situation where the set of possible translations
includes interpretations that are not acceptable to you. But for any unit
of source code there will always be some person for whom some nonempty
subset of the set of possible translations is not acceptable, so unless the
set of possible translations is singular there will always be "ambiguity"
to some person.

If the intent of a piece of code is ambiguous, the system which executes it
> has no way of knowing if the ambiguity is intentional, because all possible
> interpretations are acceptable to the creator, or accidental, because the
> programmer believed that some particular interpretation was the only
> possible one.  If the interpretation chosen by the system matches the
> expectation of the programmer, the ambiguity may go undetected for a long
> time, until the system changes and picks a different interpretation.  If it
> is believed that a programming language should be able to express ambiguity
> of intent, then that ambiguity should be clearly spelled out so that both
> programmer and execution system can agree that the ambiguity is wanted.
>

The ambiguity is clearly spelled out in the standard - just look for
"unspecified", "undefined", etc.


> That fact that coding guidelines warn against depending on order of
> evaluation is a sign that the authors of the guidelines believe that even
> the appearance of ambiguity leads to problems.  Codifying actual ambiguity
> into the language can only make problems worse - in the former
> specified-but-suspicious case, the code may be obscure but both programmer
> and execution system will permanently agree on what it means.  In the
> latter suspicious-and-unspecified case, the programmer will iterate until
> the current execution system appears to match the intent of the code, and
> then the other possible legal intents will go unnoticed until some future
> time, and havoc ensues.
>

If you're programming by permutation, and have no code review to spot
suspicious constructs, then order of evaluation issues are the least of
your worries.


> There is abundant evidence from decades of discussion that programmers,
> even expert ones, do not understand the rules controlling order of
> evaluation in C and C++.  That alone is sufficient reason to fix the rules.
>

Experts get too hung up on the rules. Confining one's efforts to clean,
idiomatic code will make things efficient and well-defined with minimal
effort.

As for the non-strict semantics of && and ||, Ada had the design right (as
> usual).  In Ada, if you want short-circuiting, you say C1 and then C2 and C1
> or else C2.  If you don't, you say C1 and C2 and C1 or C2.  In Ada, you
> can't overload the short-circuit forms, so there isn't the ambiguity
> between built-in and overloaded operators.
>

Yes, I agree. For another point of comparison, how about functional
languages, e.g. Haskell? - I wonder whether the short-circuiting in the
logical operators would have been necessary if we had had guards via
pattern matching.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0111be1cc2d0c505278191ad
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, Dec 21, 2015 at 4:54 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.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">Optimiza=
tion is the choosing of one of a set of possible translations of a code wri=
tten in one programming language into another in a way that expresses the i=
ntent of the source and satisfies some other criteria.=C2=A0 It is not nece=
ssary for the intent of the source to be ambiguous,<br></div></blockquote><=
div><br></div><div>In the way you&#39;re using it, &quot;ambiguous&quot; is=
 a value judgement; you&#39;re using it to indicate the situation where the=
 set of possible translations includes interpretations that are not accepta=
ble to you. But for any unit of source code there will always be some perso=
n for whom some nonempty subset of the set of possible translations is not =
acceptable, so unless the set of possible translations is singular there wi=
ll always be &quot;ambiguity&quot; to some person.</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">If the intent of a piece of cod=
e is ambiguous, the system which executes it has no way of knowing if the a=
mbiguity is intentional, because all possible interpretations are acceptabl=
e to the creator, or accidental, because the programmer believed that some =
particular interpretation was the only possible one.=C2=A0 If the interpret=
ation chosen by the system matches the expectation of the programmer, the a=
mbiguity may go undetected for a long time, until the system changes and pi=
cks a different interpretation.=C2=A0 If it is believed that a programming =
language should be able to express ambiguity of intent, then that ambiguity=
 should be clearly spelled out so that both programmer and execution system=
 can agree that the ambiguity is wanted.<br></div></blockquote><div><br></d=
iv><div>The ambiguity is clearly spelled out in the standard - just look fo=
r &quot;unspecified&quot;, &quot;undefined&quot;, etc.</div><div>=C2=A0<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">That fact that coding=
 guidelines warn against depending on order of evaluation is a sign that th=
e authors of the guidelines believe that even the appearance of ambiguity l=
eads to problems.=C2=A0 Codifying actual ambiguity into the language can on=
ly make problems worse - in the former specified-but-suspicious case, the c=
ode may be obscure but both programmer and execution system will permanentl=
y agree on what it means.=C2=A0 In the latter suspicious-and-unspecified ca=
se, the programmer will iterate until the current execution system appears =
to match the intent of the code, and then the other possible legal intents =
will go unnoticed until some future time, and havoc ensues.<br></div></bloc=
kquote><div><br></div><div>If you&#39;re programming by permutation, and ha=
ve no code review to spot suspicious constructs, then order of evaluation i=
ssues are the least of your worries.</div><div>=C2=A0</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">There is abundant evidence from decades of =
discussion that programmers, even expert ones, do not understand the rules =
controlling order of evaluation in C and C++.=C2=A0 That alone is sufficien=
t reason to fix the rules.<br></div></blockquote><div><br></div><div>Expert=
s get too hung up on the rules. Confining one&#39;s efforts to clean, idiom=
atic code will make things efficient and well-defined with minimal effort.<=
/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">As for =
the non-strict semantics of &amp;&amp; and ||, Ada had the design right (as=
 usual).=C2=A0 In Ada, if you want short-circuiting, you say <font face=3D"=
monospace, monospace">C1 and then C2</font> and <font face=3D"monospace, mo=
nospace">C1 or else C2</font>.=C2=A0 If you don&#39;t, you say <font face=
=3D"monospace, monospace">C1 and C2</font> and <font face=3D"monospace, mon=
ospace">C1 or C2</font>.=C2=A0 In Ada, you can&#39;t overload the short-cir=
cuit forms, so there isn&#39;t the ambiguity between built-in and overloade=
d operators.</div></blockquote><div><br></div><div>Yes, I agree. For anothe=
r point of comparison, how about functional languages, e.g. Haskell? - I wo=
nder whether the short-circuiting in the logical operators would have been =
necessary if we had had guards via pattern matching.</div></div></div></div=
>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e0111be1cc2d0c505278191ad--

.

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

On Mon, Dec 21, 2015 at 8:24 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> As well, modern architectures pass function arguments in registers, so
> pushing on the stack isn't really an issue.
>

Register usage is still an issue, though; if you can reorder subexpressions
then you can end up with the right arguments in the correct registers with
less effort than if they have to be computed strict left-to-right.

On Mon, Dec 21, 2015 at 1:41 PM, <inkwizytoryankes@gmail.com> wrote:
>
>>
>> Why you or others need express unsequenced evaluation? What it will give
>> you and what is difference compared to using sequenced call? In function
>> arguments passing it can simplify pushing values on stack, but here you
>> don't use it, then what is goal?
>>
>> Other goals per above; load/store coalescing, dependent CSE (on
subexpressions and on inlined function calls), pipelining, branch
elimination, speculative execution. The more latitude given to the
optimizer, the better (more performant) code it can emit.


>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113ed14a8561cc052781a5b7
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, Dec 21, 2015 at 8:24 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt=
;</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">As well, modern archit=
ectures pass function arguments in registers, so pushing on the stack isn&#=
39;t really an issue.</div></blockquote><div><br></div><div>Register usage =
is still an issue, though; if you can reorder subexpressions then you can e=
nd up with the right arguments in the correct registers with less effort th=
an if they have to be computed strict left-to-right.</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span =
class=3D"">On Mon, Dec 21, 2015 at 1:41 PM,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:inkwizytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@g=
mail.com</a>&gt;</span> wrote:<br></span><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">=
<div><br>Why you or others need express unsequenced evaluation? What it wil=
l give you and what is difference compared to using sequenced call? In func=
tion arguments passing it can simplify pushing values on stack, but here yo=
u don&#39;t use it, then what is goal?<br></div></span><div><div>

<p></p></div></div></blockquote></div></div></blockquote></div><div>Other g=
oals per above; load/store coalescing, dependent CSE (on subexpressions and=
 on inlined function calls), pipelining, branch elimination, speculative ex=
ecution. The more latitude given to the optimizer, the better (more perform=
ant) code it can emit.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=3D=
"gmail_extra"></div></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113ed14a8561cc052781a5b7--

.

------=_Part_15_896307555.1450838734117
Content-Type: multipart/alternative;
 boundary="----=_Part_16_1071268756.1450838734117"

------=_Part_16_1071268756.1450838734117
Content-Type: text/plain; charset=UTF-8


On Tuesday, December 22, 2015 at 2:25:35 PM UTC-5, Edward Catmur wrote:
>
> On Mon, Dec 21, 2015 at 4:54 PM, Hyman Rosen <hyman...@gmail.com
> <javascript:>> wrote:
>
>>
>>
> That fact that coding guidelines warn against depending on order of
>> evaluation is a sign that the authors of the guidelines believe that even
>> the appearance of ambiguity leads to problems.  Codifying actual ambiguity
>> into the language can only make problems worse - in the former
>> specified-but-suspicious case, the code may be obscure but both programmer
>> and execution system will permanently agree on what it means.  In the
>> latter suspicious-and-unspecified case, the programmer will iterate until
>> the current execution system appears to match the intent of the code, and
>> then the other possible legal intents will go unnoticed until some future
>> time, and havoc ensues.
>>
>
> If you're programming by permutation, and have no code review to spot
> suspicious constructs, then order of evaluation issues are the least of
> your worries.
>
>

I thought the whole point of wanting to nail down a particular order of
evaluation is precisely because its difficult to tell by looking at such
dubious constructs whether they are ill-formed or someone just being
incredibly clever. The subsequent point Hyman makes below about even
experts being confused about this from time to time ties in with this.
Given that, I don't understand how code reviews are supposed to catch
something no one is clear about today.

We had a round of discussion about this with the authors themselves and for
all the pushback they gave us in not nailing down a single (left-to-right)
order of evaluation, not once did they bring up the optimization
argument.

I guess this goes to prove that as long as the "But Optmizations!" (not my
phrasing, I borrowed it from my mentor!) crowd have their way, this
proposal is DOA.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br>On Tuesday, December 22, 2015 at 2:25:35 PM UTC-5, Edward Catmur wrote:=
<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">On Mon, Dec 21, 2015 at 4:54 PM, Hyman Rosen <span dir=
=3D"ltr">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"java=
script:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"02zzAy=
kkDwAJ">hyman...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">=C2=A0<br></blockquote><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">That fact that coding guidelines warn against depending on order of eva=
luation is a sign that the authors of the guidelines believe that even the =
appearance of ambiguity leads to problems.=C2=A0 Codifying actual ambiguity=
 into the language can only make problems worse - in the former specified-b=
ut-suspicious case, the code may be obscure but both programmer and executi=
on system will permanently agree on what it means.=C2=A0 In the latter susp=
icious-and-unspecified case, the programmer will iterate until the current =
execution system appears to match the intent of the code, and then the othe=
r possible legal intents will go unnoticed until some future time, and havo=
c ensues.<br></div></blockquote><div><br></div><div>If you&#39;re programmi=
ng by permutation, and have no code review to spot suspicious constructs, t=
hen order of evaluation issues are the least of your worries.</div><div>=C2=
=A0</div></div></div></div></blockquote><div><br></div><div>I thought=C2=A0=
the whole point=C2=A0of wanting=C2=A0to nail down a particular order of eva=
luation is precisely because its=C2=A0difficult to tell=C2=A0by looking at =
such dubious constructs whether they are ill-formed=C2=A0or someone just be=
ing incredibly clever. The subsequent point Hyman makes below about even ex=
perts being confused about this from time to time ties in with=C2=A0this. G=
iven that, I don&#39;t understand how code reviews are supposed to catch so=
mething no one is clear=C2=A0about today.</div><div><br></div><div>We had a=
 round of discussion about this with the authors themselves and for all the=
 pushback they gave us in not nailing down a single (left-to-right) order o=
f evaluation, not once did they bring up the optimization </div><div>argume=
nt.</div><div><br></div><div>I guess this goes to prove that as long as the=
 &quot;But Optmizations!&quot; (not my phrasing, I borrowed it from my ment=
or!) crowd have their way, this proposal is DOA.</div><div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_16_1071268756.1450838734117--
------=_Part_15_896307555.1450838734117--

.

------=_Part_89_1731103402.1450841118448
Content-Type: multipart/alternative;
 boundary="----=_Part_90_416319627.1450841118448"

------=_Part_90_416319627.1450841118448
Content-Type: text/plain; charset=UTF-8

To me, this whole discussion is a no-brainer. Use left-to-right evaluation
order and be done with it. Left-to-right evaluation eliminates a whole raft
of subtle and hard-to-spot bugs, it creates one simple rule that everyone
can easily understand, and it follows the convention established by a bunch
of other languages.

This obsession with efficiency has to stop, particularly when it comes at
the cost of creating an ergonomic train wreck of rules that only
language-lawyers can understand. The optimisations that are lost by
defining the evaluation order hardly ever kick in and, when they do, they
are peep-hole optimisations. If I am *that* desperate to squeeze that last
ounce on performance, I should probably be writing assembly anyway. I
certainly shouldn't be relying on an optimiser getting me over the line by
being clever with evaluation order because the optimiser can change its
behaviour at any time, and optimisers for different compilers may do it
differently.

Michi.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">To me, this whole discussion is a no-brainer. Use left-to-=
right evaluation order and be done with it. Left-to-right evaluation elimin=
ates a whole raft of subtle and hard-to-spot bugs, it creates one simple ru=
le that everyone can easily understand, and it follows the convention estab=
lished by a bunch of other languages.<div><br></div><div>This obsession wit=
h efficiency has to stop, particularly when it comes at the cost of creatin=
g an ergonomic train wreck of rules that only language-lawyers can understa=
nd. The optimisations that are lost by defining the evaluation order hardly=
 ever kick in and, when they do, they are peep-hole optimisations. If I am =
*that* desperate to squeeze that last ounce on performance, I should probab=
ly be writing assembly anyway. I certainly shouldn&#39;t be relying on an o=
ptimiser getting me over the line by being clever with evaluation order bec=
ause the optimiser can change its behaviour at any time, and optimisers for=
 different compilers may do it differently.</div><div><br></div><div>Michi.=
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_90_416319627.1450841118448--
------=_Part_89_1731103402.1450841118448--

.

--Apple-Mail=_5B3A7EEC-24B1-4CAF-AC89-5AF6C77D0BD0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9312=E2=80=9323, at 11:25 AM, michi.henning@canonical.com w=
rote:
>=20
> To me, this whole discussion is a no-brainer. Use left-to-right evaluatio=
n order and be done with it. Left-to-right evaluation eliminates a whole ra=
ft of subtle and hard-to-spot bugs, it creates one simple rule that everyon=
e can easily understand, and it follows the convention established by a bun=
ch of other languages.

Left-to-right evaluation enables multiple side-effects within an expression=
, particularly in method chaining <https://en.wikipedia.org/wiki/Method_cha=
ining> (and its cousin, operator<<) and calls with several arguments. This =
is generally poor style. However, it=E2=80=99s ineffective to legislate sty=
le by =E2=80=9Cscary=E2=80=9D UB.

> This obsession with efficiency has to stop, particularly when it comes at=
 the cost of creating an ergonomic train wreck of rules that only language-=
lawyers can understand.

The rule is, =E2=80=9Cdon=E2=80=99t modify a variable and also use it withi=
n the same line.=E2=80=9D It=E2=80=99s simple, but indeed, for many that sh=
ip has sailed.

(The (new X)->f() example is overboard =E2=80=94 no implementation would ev=
er get that wrong, and it=E2=80=99s simply a defect if X::X() isn=E2=80=99t=
 ordered before X::f(). The language can solve things like that without uni=
form left-to-right everywhere.)

> The optimisations that are lost by defining the evaluation order hardly e=
ver kick in and, when they do, they are peep-hole optimizations.

What peephole optimization?

Unordered evaluation allows the compiler to ignore aliasing. Modern compile=
rs are better at moving loads and stores past semicolons, so they should al=
so be less disturbed by additional sequencing within expressions. Aliasing =
is a tricky problem with tricky solutions, so it=E2=80=99s hard to guesstim=
ate the performance impact.

Left-to-right evaluation is pessimal for CPUs that require arguments to be =
pushed in right-to-left order, such as Coldfire, some 32-bit x86 ABIs, s/39=
0, and other CISCs. An argument which is computed first but passed last wil=
l increase the register pressure, and such machines have few registers. How=
ever=E2=80=A6

The proposal has been met little controversy in over a year of discussion a=
t the meetings. Anyone facing an actual impact should measure it and write =
a paper. Mere speculation isn=E2=80=99t very helpful. This thread seems lik=
e a waste of breath as long as no data is presented, but fortunately, it do=
esn=E2=80=99t seem to reflect what I saw at ISO.

Still, it would be nice to see someone collect the experimental data.

> If I am *that* desperate to squeeze that last ounce on performance, I sho=
uld probably be writing assembly anyway. I certainly shouldn't be relying o=
n an optimiser getting me over the line by being clever with evaluation ord=
er because the optimiser can change its behaviour at any time, and optimise=
rs for different compilers may do it differently.

It=E2=80=99s pretty tricky to hand-optimize even a small function. It=E2=80=
=99s a non-starter solution for a tax spread over the whole code base. If s=
omeone=E2=80=99s really serious about complaining, they simply need to quan=
tify that tax.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--Apple-Mail=_5B3A7EEC-24B1-4CAF-AC89-5AF6C77D0BD0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9312=
=E2=80=9323, at 11:25 AM, <a href=3D"mailto:michi.henning@canonical.com" cl=
ass=3D"">michi.henning@canonical.com</a> wrote:</div><br class=3D"Apple-int=
erchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">To me, this w=
hole discussion is a no-brainer. Use left-to-right evaluation order and be =
done with it. Left-to-right evaluation eliminates a whole raft of subtle an=
d hard-to-spot bugs, it creates one simple rule that everyone can easily un=
derstand, and it follows the convention established by a bunch of other lan=
guages.</div></div></blockquote><div><br class=3D""></div><div>Left-to-righ=
t evaluation enables multiple side-effects within an expression, particular=
ly in&nbsp;<a href=3D"https://en.wikipedia.org/wiki/Method_chaining" class=
=3D"">method chaining</a>&nbsp;(and its cousin, <font face=3D"Courier" clas=
s=3D"">operator&lt;&lt;</font>)&nbsp;and calls with several arguments. This=
 is generally poor style. However, it=E2=80=99s ineffective to legislate st=
yle by =E2=80=9Cscary=E2=80=9D UB.</div><div><br class=3D""></div><blockquo=
te type=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Thi=
s obsession with efficiency has to stop, particularly when it comes at the =
cost of creating an ergonomic train wreck of rules that only language-lawye=
rs can understand.</div></div></blockquote><div><br class=3D""></div><div>T=
he rule is, =E2=80=9Cdon=E2=80=99t modify a variable and also use it within=
 the same line.=E2=80=9D It=E2=80=99s simple, but indeed, for many that shi=
p has sailed.</div><div><br class=3D""></div><div>(The <font face=3D"Courie=
r" class=3D"">(new X)-&gt;f()</font> example is overboard =E2=80=94 no impl=
ementation would ever get that wrong, and it=E2=80=99s simply a defect if <=
font face=3D"Courier" class=3D"">X::X()</font> isn=E2=80=99t ordered before=
 <font face=3D"Courier" class=3D"">X::f()</font>. The language can solve th=
ings like that without uniform left-to-right everywhere.)</div><br class=3D=
""><blockquote type=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div cl=
ass=3D"">The optimisations that are lost by defining the evaluation order h=
ardly ever kick in and, when they do, they are peep-hole optimizations. </d=
iv></div></blockquote><div><br class=3D""></div><div>What peephole optimiza=
tion?</div><div><br class=3D""></div><div>Unordered evaluation allows the c=
ompiler to ignore aliasing. Modern compilers are better at moving loads and=
 stores past semicolons, so they should also be less disturbed by additiona=
l sequencing within expressions. Aliasing is a tricky problem with tricky s=
olutions, so it=E2=80=99s hard to guesstimate the performance impact.</div>=
<div><br class=3D""></div><div>Left-to-right evaluation is pessimal for CPU=
s that require arguments to be pushed in right-to-left order, such as Coldf=
ire, some 32-bit x86 ABIs, s/390, and other CISCs. An argument which is com=
puted first but passed last will increase the register pressure, and such m=
achines have few registers. However=E2=80=A6</div><div><br class=3D""></div=
><div>The proposal has been met little controversy in over a year of discus=
sion at the meetings. Anyone facing an actual impact should measure it and =
write a paper. Mere speculation isn=E2=80=99t very helpful. This thread see=
ms like a waste of breath as long as no data is presented, but fortunately,=
 it doesn=E2=80=99t seem to reflect what I saw at ISO.</div><div><br class=
=3D""></div><div>Still, it would be nice to see someone collect the experim=
ental data.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div d=
ir=3D"ltr" class=3D""><div class=3D"">If I am *that* desperate to squeeze t=
hat last ounce on performance, I should probably be writing assembly anyway=
.. I certainly shouldn't be relying on an optimiser getting me over the line=
 by being clever with evaluation order because the optimiser can change its=
 behaviour at any time, and optimisers for different compilers may do it di=
fferently.</div></div></blockquote><br class=3D""></div><div>It=E2=80=99s p=
retty tricky to hand-optimize even a small function. It=E2=80=99s&nbsp;a no=
n-starter solution for a tax spread over the whole code base. If someone=E2=
=80=99s really serious about complaining, they simply need to quantify that=
 tax.</div><br class=3D""></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--Apple-Mail=_5B3A7EEC-24B1-4CAF-AC89-5AF6C77D0BD0--

.

------=_Part_758_1427235083.1450879299387
Content-Type: multipart/alternative;
 boundary="----=_Part_759_1229369690.1450879299387"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UT=
C+8=E4=B8=8A=E5=8D=882:41:24=EF=BC=8Cinkwizyt...@gmail.com=E5=86=99=E9=81=
=93=EF=BC=9A
>
>
>
> On Monday, December 21, 2015 at 8:30:49 AM UTC+1, FrankHB1989 wrote:
>>
>>
>> The only reason for thinking that leaving order of evaluation unspecifie=
d=20
>>> is good is because of Stockholm Syndrome - it has been this way for so =
long=20
>>> that people have found reasons for believing this way is right rather t=
han=20
>>> fighting against it.
>>>
>> Again, that's *you*. You, as well as some others, may have no need to=20
>> express unsequenced evaluations, but there are people who have it with=
=20
>> quite valid reasons to make the feature "portable". On the contrary, you=
=20
>> are trying to abduct others' requirements to the language based on your=
=20
>> need, or the need you imagine the users of the language should have. Who=
=20
>> are the victims of Stockholm Syndrome?
>>
>
> Why you or others need express unsequenced evaluation? What it will give=
=20
> you and what is difference compared to using sequenced call? In function=
=20
> arguments passing it can simplify pushing values on stack, but here you=
=20
> don't use it, then what is goal?
>

It is mainly to emphasize the intent of the author: I know the order of=20
specific subexpressions does not matter, so I don't care the order=20
intentionally here. It may be better to provide additional syntax sugar=20
(strictly speaking, not needed in the core language) to tag the specific=20
code. The implementation (usually a compiler) is then free to reorder the=
=20
specific evaluation, so it would also benefit the optimization. If=20
sequenced call rules are enforced, comments can still achieve the main=20
intent. However, it would be with less precision (concerned with location=
=20
of the subexpressions) and wordy. Some previously available optimization=20
would also be impossible without extensions. *The latter is a net lost.*

How arguments are passed is not related to the topic. ISO C++ does not=20
require an implementation to use a call stack to implement function calls.=
=20
The only "stack" terminology concerned in the standard is "stack=20
unwinding". As noted, code generated by typical modern implementations=20
would pass arguments by registers, which is now not touched by C++ at all.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=8C UTC+8=E4=B8=8A=E5=8D=882:41:24=EF=BC=8Cinkwizyt...@gmail.com=E5=86=
=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>O=
n Monday, December 21, 2015 at 8:30:49 AM UTC+1, 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"><br><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>The only reason for =
thinking that leaving order of evaluation unspecified is good is because of=
 Stockholm Syndrome - it has been this way for so long that people have fou=
nd reasons for believing this way is right rather than fighting against it.=
</div></div></div></div></blockquote><div>Again, that&#39;s <i>you</i>. You=
, as well as some others, may have no need to express unsequenced evaluatio=
ns, but there are people who have it with quite valid reasons to make the f=
eature &quot;portable&quot;. On the contrary, you are trying to abduct othe=
rs&#39; requirements to the language based on your need, or the need you im=
agine the users of the language should have. Who are the victims of Stockho=
lm Syndrome?</div></blockquote><div><br>Why you or others need express unse=
quenced evaluation? What it will give you and what is difference compared t=
o using sequenced call? In function arguments passing it can simplify pushi=
ng values on stack, but here you don&#39;t use it, then what is goal?<br></=
div></blockquote><div><br>It is mainly to emphasize the intent of the autho=
r: I know the order of specific subexpressions does not matter, so I don&#3=
9;t care the order intentionally here. It may be better to provide addition=
al syntax sugar (strictly speaking, not needed in the core language) to tag=
 the specific code. The implementation (usually a compiler) is then free to=
 reorder the specific evaluation, so it would also benefit the optimization=
.. If sequenced call rules are enforced, comments can still achieve the main=
 intent. However, it would be with less precision (concerned with location =
of the subexpressions) and wordy. Some previously available optimization wo=
uld also be impossible without extensions. <b>The latter is a net lost.</b>=
<br><br>How arguments are passed is not related to the topic. ISO C++ does =
not require an implementation to use a call stack to implement function cal=
ls. The only &quot;stack&quot; terminology concerned in the standard is &qu=
ot;stack unwinding&quot;. As noted, code generated by typical modern implem=
entations would pass arguments by registers, which is now not touched by C+=
+ at all.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_759_1229369690.1450879299387--
------=_Part_758_1427235083.1450879299387--

.

------=_Part_792_583595717.1450880455904
Content-Type: multipart/alternative;
 boundary="----=_Part_793_1242508822.1450880455904"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8B=E5=8D=882:47:52=EF=BC=8CDavid Krauss=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
> The optimisations that are lost by defining the evaluation order hardly=
=20
> ever kick in and, when they do, they are peep-hole optimizations.=20
>
>
> What peephole optimization?
>
> Unordered evaluation allows the compiler to ignore aliasing. Modern=20
> compilers are better at moving loads and stores past semicolons, so they=
=20
> should also be less disturbed by additional sequencing within expressions=
..=20
> Aliasing is a tricky problem with tricky solutions, so it=E2=80=99s hard =
to=20
> guesstimate the performance impact.
>
> Left-to-right evaluation is pessimal for CPUs that require arguments to b=
e=20
> pushed in right-to-left order, such as Coldfire, some 32-bit x86 ABIs,=20
> s/390, and other CISCs. An argument which is computed first but passed la=
st=20
> will increase the register pressure, and such machines have few registers=
..=20
> However=E2=80=A6
>
> The proposal has been met little controversy in over a year of discussion=
=20
> at the meetings. Anyone facing an actual impact should measure it and wri=
te=20
> a paper. Mere speculation isn=E2=80=99t very helpful. This thread seems l=
ike a=20
> waste of breath as long as no data is presented, but fortunately, it=20
> doesn=E2=80=99t seem to reflect what I saw at ISO.
>
> Still, it would be nice to see someone collect the experimental data.
>

For a high level language, there is one thing come before the optimization:=
=20
expressiveness, which determines the possible interpretation of the code.=
=20
Opportunity of optimization is granted by a few rules (the "as-if" rule and=
=20
several other semantics exceptions like rules for copy elision) based on=20
the expressiveness. It will be lost if the new rules are strictly=20
restrictive than before. (Any doubt?)

Whether it is significant enough or not, is another story. The data would=
=20
be good to illustrate *this *significance, but far from the complete for=20
decision of the evolution, since the change would have *limited users'=20
valid choice* and *no replacement is provided*.



--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=89 UTC+8=E4=B8=8B=E5=8D=882:47:52=EF=BC=8CDavid Krauss=E5=86=99=E9=81=
=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word=
-wrap:break-word"><br><div><blockquote type=3D"cite"><div dir=3D"ltr"><div>=
The optimisations that are lost by defining the evaluation order hardly eve=
r kick in and, when they do, they are peep-hole optimizations. </div></div>=
</blockquote><div><br></div><div>What peephole optimization?</div><div><br>=
</div><div>Unordered evaluation allows the compiler to ignore aliasing. Mod=
ern compilers are better at moving loads and stores past semicolons, so the=
y should also be less disturbed by additional sequencing within expressions=
.. Aliasing is a tricky problem with tricky solutions, so it=E2=80=99s hard =
to guesstimate the performance impact.</div><div><br></div><div>Left-to-rig=
ht evaluation is pessimal for CPUs that require arguments to be pushed in r=
ight-to-left order, such as Coldfire, some 32-bit x86 ABIs, s/390, and othe=
r CISCs. An argument which is computed first but passed last will increase =
the register pressure, and such machines have few registers. However=E2=80=
=A6</div><div><br></div><div>The proposal has been met little controversy i=
n over a year of discussion at the meetings. Anyone facing an actual impact=
 should measure it and write a paper. Mere speculation isn=E2=80=99t very h=
elpful. This thread seems like a waste of breath as long as no data is pres=
ented, but fortunately, it doesn=E2=80=99t seem to reflect what I saw at IS=
O.</div><div><br></div><div>Still, it would be nice to see someone collect =
the experimental data.</div></div></div></blockquote><div><br>For a high le=
vel language, there is one thing come before the optimization: expressivene=
ss, which determines the possible interpretation of the code. Opportunity o=
f optimization is granted by a few rules (the &quot;as-if&quot; rule and se=
veral other semantics exceptions like rules for copy elision) based on the =
expressiveness. It will be lost if the new rules are strictly restrictive t=
han before. (Any doubt?)<br><br>Whether it is significant enough or not, is=
 another story. The data would be good to illustrate <b>this </b>significan=
ce, but far from the complete for decision of the evolution, since the chan=
ge would have <b>limited users&#39; valid choice</b> and <b>no replacement =
is provided</b>.<br><br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_793_1242508822.1450880455904--
------=_Part_792_583595717.1450880455904--

.

--Apple-Mail=_191BF315-41F3-4A59-9480-65E467EF0E4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9312=E2=80=9323, at 10:20 PM, FrankHB1989 <frankhb1989@gmai=
l.com> wrote:
>=20
> For a high level language, there is one thing come before the optimizatio=
n: expressiveness, which determines the possible interpretation of the code=
.. Opportunity of optimization is granted by a few rules (the "as-if" rule a=
nd several other semantics exceptions like rules for copy elision) based on=
 the expressiveness. It will be lost if the new rules are strictly restrict=
ive than before. (Any doubt?)
>=20
> Whether it is significant enough or not, is another story. The data would=
 be good to illustrate this significance, but far from the complete for dec=
ision of the evolution, since the change would have limited users' valid ch=
oice and no replacement is provided.

What do rules of uncertainty, such as copy elision and unordered operations=
, usefully express besides optimization opportunities? If the optimization =
is of insignificant value, that would seem to imply that the rule is ripe f=
or elimination.

The analysis is similar for guaranteed copy elision, which has also been ad=
ded to C++17: the language (i.e., its designers) never intended to express =
uncertainty, but only to run fast. Corner cases even exist where P0135R0 ac=
tually eliminates copy elision, but they are considered insignificant.

The as-if rule isn=E2=80=99t a distinct rule at all, it=E2=80=99s just a cl=
arification of the fact that the standard only describes a distinct set of =
behaviors when a computer runs a program that was written in C++.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--Apple-Mail=_191BF315-41F3-4A59-9480-65E467EF0E4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9312=
=E2=80=9323, at 10:20 PM, FrankHB1989 &lt;<a href=3D"mailto:frankhb1989@gma=
il.com" class=3D"">frankhb1989@gmail.com</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D"">For a high level language, there =
is one thing come before the optimization: expressiveness, which determines=
 the possible interpretation of the code. Opportunity of optimization is gr=
anted by a few rules (the "as-if" rule and several other semantics exceptio=
ns like rules for copy elision) based on the expressiveness. It will be los=
t if the new rules are strictly restrictive than before. (Any doubt?)<br cl=
ass=3D""><div class=3D""><br class=3D"">Whether it is significant enough or=
 not, is another story. The data would be good to illustrate <b class=3D"">=
this </b>significance, but far from the complete for decision of the evolut=
ion, since the change would have <b class=3D"">limited users' valid choice<=
/b> and <b class=3D"">no replacement is provided</b>.<br class=3D""></div><=
/div></blockquote><div><br class=3D""></div><div>What do rules of uncertain=
ty, such as copy elision and unordered operations, usefully express besides=
 optimization opportunities? If the optimization is of insignificant value,=
 that would seem to imply that the rule is ripe for elimination.</div><div>=
<br class=3D""></div><div>The analysis is similar for guaranteed copy elisi=
on, which has also been added to C++17: the language (i.e., its designers) =
never intended to express uncertainty, but only to run fast. Corner cases e=
ven exist where P0135R0 actually eliminates copy elision, but they are cons=
idered insignificant.</div></div><div class=3D""><br class=3D""></div><div =
class=3D"">The as-if rule isn=E2=80=99t a distinct rule at all, it=E2=80=99=
s just a clarification of the fact that the standard only describes a disti=
nct set of behaviors when a computer runs a program that was written in C++=
..</div><div class=3D""><br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--Apple-Mail=_191BF315-41F3-4A59-9480-65E467EF0E4B--

.

--047d7bdca440af8717052792b86b
Content-Type: text/plain; charset=UTF-8

On Wed, Dec 23, 2015 at 2:45 AM, <misc.usage@gmail.com> wrote:

> I thought the whole point of wanting to nail down a particular order of
> evaluation is precisely because its difficult to tell by looking at such
> dubious constructs whether they are ill-formed or someone just being
> incredibly clever. The subsequent point Hyman makes below about even
> experts being confused about this from time to time ties in with this.
> Given that, I don't understand how code reviews are supposed to catch
> something no one is clear about today.
>

If it's unclear, it should be rejected at code review. "Incredibly clever"
is a definite demerit, as it prevents code being maintained by other team
members whose cleverness may not extend in the same directions, or debugged
at 3am.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bdca440af8717052792b86b
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, Dec 23, 2015 at 2:45 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:misc.=
usage@gmail.com" target=3D"_blank">misc.usage@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div>I thought=C2=A0the whole point=C2=
=A0of wanting=C2=A0to nail down a particular order of evaluation is precise=
ly because its=C2=A0difficult to tell=C2=A0by looking at such dubious const=
ructs whether they are ill-formed=C2=A0or someone just being incredibly cle=
ver. The subsequent point Hyman makes below about even experts being confus=
ed about this from time to time ties in with=C2=A0this. Given that, I don&#=
39;t understand how code reviews are supposed to catch something no one is =
clear=C2=A0about today.</div></blockquote><div><br></div><div>If it&#39;s u=
nclear, it should be rejected at code review. &quot;Incredibly clever&quot;=
 is a definite demerit, as it prevents code being maintained by other team =
members whose cleverness may not extend in the same directions, or debugged=
 at 3am.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7bdca440af8717052792b86b--

.

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

A programming language is a means for a programmer to instruct a computer
to carry out a computation.  If the meaning of a program is sufficiently
underspecified such that the computer can carry out a variety of
computations with different effects, this leads to serious possibility of
error in the case where the programmer did not realize that some
interpretation was possible and the one chosen by the implementation was
the one that the programmer expected, because at some point in the future,
the implementation may choose the unwelcome interpretation.

Code review is no answer - the questionable constructs do not have to be
clever.  Consider the Qt expression previously posted:

textLayout()->nextCursorPosition(m_cursor) - m_cursor

To fail code review, a reviewer must realize that nextCursorPosition can
modify m_cursor and that therefore the two uses of it in the expression
might not have the same value, and that it's legitimate for the
implementation to interpret this in two different ways.  Guaranteed, this
will be missed much of the time.  It is therefore necessary that such
constructs have only a single interpretation, in which case it will match
the programmer's expectation now and forever, or it will not and the
programmer will fix it.

If it is desirable to have the implementation pick from a set of possible
interpretations then the programming language should provide a way of
saying so explicitly, so that readers of the program can see this clearly.

We should not ask programmers to =E2=80=9Cdon=E2=80=99t modify a variable a=
nd also use it
within the same line=E2=80=9D any more than we ask them to "don't call two
functions within the same line".  The reason we have the former rule is
that our programming languages have bad specifications.  The notion that we
can work around this by telling programmers not to be clever is dead wrong
- the problem occurs when programmers do not realize that they have been
clever, and just think they have written code with one meaning.

On Wed, Dec 23, 2015 at 10:53 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Wed, Dec 23, 2015 at 2:45 AM, <misc.usage@gmail.com> wrote:
>
>> I thought the whole point of wanting to nail down a particular order of
>> evaluation is precisely because its difficult to tell by looking at such
>> dubious constructs whether they are ill-formed or someone just being
>> incredibly clever. The subsequent point Hyman makes below about even
>> experts being confused about this from time to time ties in with this.
>> Given that, I don't understand how code reviews are supposed to catch
>> something no one is clear about today.
>>
>
> If it's unclear, it should be rejected at code review. "Incredibly clever=
"
> is a definite demerit, as it prevents code being maintained by other team
> members whose cleverness may not extend in the same directions, or debugg=
ed
> at 3am.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">A programming language is a means for a programmer to inst=
ruct a computer to carry out a computation.=C2=A0 If the meaning of a progr=
am is sufficiently underspecified such that the computer can carry out a va=
riety of computations with different effects, this leads to serious possibi=
lity of error in the case where the programmer did not realize that some in=
terpretation was possible and the one chosen by the implementation was the =
one that the programmer expected, because at some point in the future, the =
implementation may choose the unwelcome interpretation.<div><br></div><div>=
Code review is no answer - the questionable constructs do not have to be cl=
ever.=C2=A0 Consider the Qt expression previously posted:<blockquote type=
=3D"cite" style=3D"color:rgb(80,0,80);font-size:12.8px"><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><table><tbody><tr><td style=3D"font-family:Consola=
s,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;padding:0px 10px;vertic=
al-align:top;font-size:12px;white-space:pre-wrap;overflow:visible;word-wrap=
:normal;background-color:rgb(248,238,199)"><span style=3D"color:rgb(0,134,1=
79)">textLayout</span>()-&gt;<span style=3D"color:rgb(0,134,179)">nextCurso=
rPosition</span>(m_cursor) - m_cursor</td></tr></tbody></table></div></div>=
</blockquote>To fail code review, a reviewer must realize that nextCursorPo=
sition can modify m_cursor and that therefore the two uses of it in the exp=
ression might not have the same value, and that it&#39;s legitimate for the=
 implementation to interpret this in two different ways.=C2=A0 Guaranteed, =
this will be missed much of the time.=C2=A0 It is therefore necessary that =
such constructs have only a single interpretation, in which case it will ma=
tch the programmer&#39;s expectation now and forever, or it will not and th=
e programmer will fix it.<br><br>If it is desirable to have the implementat=
ion pick from a set of possible interpretations then the programming langua=
ge should provide a way of saying so explicitly, so that readers of the pro=
gram can see this clearly.<br><br>We should not ask programmers to <span st=
yle=3D"font-size:12.8px">=E2=80=9Cdon=E2=80=99t modify a variable and also =
use it within the same line=E2=80=9D any more than we ask them to &quot;don=
&#39;t call two functions within the same line&quot;.=C2=A0 The reason we h=
ave the former rule is that our programming languages have bad specificatio=
ns.=C2=A0 The notion that we can work around this by telling programmers no=
t to be clever is dead wrong - the problem occurs when programmers do not r=
ealize that they have been clever, and just think they have written code wi=
th one meaning.</span></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Dec 23, 2015 at 10:53 AM, &#39;Edward Catmur&#39; =
via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</=
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"><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Wed,=
 Dec 23, 2015 at 2:45 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:misc.usa=
ge@gmail.com" target=3D"_blank">misc.usage@gmail.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>I thought=C2=A0the whole point=C2=A0=
of wanting=C2=A0to nail down a particular order of evaluation is precisely =
because its=C2=A0difficult to tell=C2=A0by looking at such dubious construc=
ts whether they are ill-formed=C2=A0or someone just being incredibly clever=
.. The subsequent point Hyman makes below about even experts being confused =
about this from time to time ties in with=C2=A0this. Given that, I don&#39;=
t understand how code reviews are supposed to catch something no one is cle=
ar=C2=A0about today.</div></blockquote><div><br></div></span><div>If it&#39=
;s unclear, it should be rejected at code review. &quot;Incredibly clever&q=
uot; is a definite demerit, as it prevents code being maintained by other t=
eam members whose cleverness may not extend in the same directions, or debu=
gged at 3am.</div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5"=
>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a114405c6c85e640527998bfa--

.

------=_Part_1075_60429288.1450922248631
Content-Type: multipart/alternative;
 boundary="----=_Part_1076_703697681.1450922248632"

------=_Part_1076_703697681.1450922248632
Content-Type: text/plain; charset=UTF-8



On Wednesday, December 23, 2015 at 10:53:22 AM UTC-5, Edward Catmur wrote:
>
> On Wed, Dec 23, 2015 at 2:45 AM, <misc....@gmail.com <javascript:>> wrote:
>
>> I thought the whole point of wanting to nail down a particular order of
>> evaluation is precisely because its difficult to tell by looking at such
>> dubious constructs whether they are ill-formed or someone just being
>> incredibly clever. The subsequent point Hyman makes below about even
>> experts being confused about this from time to time ties in with this.
>> Given that, I don't understand how code reviews are supposed to catch
>> something no one is clear about today.
>>
>
> If it's unclear, it should be rejected at code review. "Incredibly clever"
> is a definite demerit, as it prevents code being maintained by other team
> members whose cleverness may not extend in the same directions, or debugged
> at 3am.
>

It's not just overly clever code that can be bitten by the
order-of-evaluation bug.  Consider the code
foo(shared_ptr<int>(new int(7)), bar());

 This code seems perfectly reasonable at first glance; new is called and
the result is immediately given to shared_ptr's constructor.  But as Scott
Meyers shows in "Effective Modern C++", if the order of evaluation of the
subexpressions is
1) new int(7)
2) bar()
3) shared_ptr constructor

and bar() throws an exception, this code can leak.   I don't think it is
reasonable to force users to have to defend against cases like this.

Joe Gottman

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Wednesday, December 23, 2015 at 10:53:22 AM UTC-5, Edward Catmur=
 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 Wed, Dec 23, 2015 at 2:45 AM,  <span dir=3D"lt=
r">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Z=
fHP3yhnDwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">misc....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div>I thought=C2=A0the whole point=C2=A0of wanting=C2=A0to nail down a p=
articular order of evaluation is precisely because its=C2=A0difficult to te=
ll=C2=A0by looking at such dubious constructs whether they are ill-formed=
=C2=A0or someone just being incredibly clever. The subsequent point Hyman m=
akes below about even experts being confused about this from time to time t=
ies in with=C2=A0this. Given that, I don&#39;t understand how code reviews =
are supposed to catch something no one is clear=C2=A0about today.</div></bl=
ockquote><div><br></div><div>If it&#39;s unclear, it should be rejected at =
code review. &quot;Incredibly clever&quot; is a definite demerit, as it pre=
vents code being maintained by other team members whose cleverness may not =
extend in the same directions, or debugged at 3am.</div></div></div></div><=
/blockquote><div><br>It&#39;s not just overly clever code that can be bitte=
n by the order-of-evaluation bug.=C2=A0 Consider the code<br><div class=3D"=
prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: r=
gb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break=
-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">foo</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">shared_ptr</span><span style=3D"color: #08=
0;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">new</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">7</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">)),</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">());</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>=
=C2=A0This code seems perfectly reasonable at first glance; new is called a=
nd the result is immediately given to shared_ptr&#39;s constructor.=C2=A0 B=
ut as Scott Meyers shows in &quot;Effective Modern C++&quot;, if the order =
of evaluation of the subexpressions is<br>1) new int(7)<br>2) bar()<br>3) s=
hared_ptr constructor<br><br>and bar() throws an exception, this code can l=
eak. =C2=A0 I don&#39;t think it is reasonable to force users to have to de=
fend against cases like this.<br><br>Joe Gottman<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1076_703697681.1450922248632--
------=_Part_1075_60429288.1450922248631--

.

------=_Part_104_811519169.1450940826999
Content-Type: multipart/alternative;
 boundary="----=_Part_105_226108060.1450940827000"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8B=E5=8D=8811:53:02=EF=BC=8CDavid Krauss=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
> On 2015=E2=80=9312=E2=80=9323, at 10:20 PM, FrankHB1989 <frank...@gmail.c=
om <javascript:>>=20
> wrote:
>
> For a high level language, there is one thing come before the=20
> optimization: expressiveness, which determines the possible interpretatio=
n=20
> of the code. Opportunity of optimization is granted by a few rules (the=
=20
> "as-if" rule and several other semantics exceptions like rules for copy=
=20
> elision) based on the expressiveness. It will be lost if the new rules ar=
e=20
> strictly restrictive than before. (Any doubt?)
>
> Whether it is significant enough or not, is another story. The data would=
=20
> be good to illustrate *this *significance, but far from the complete for=
=20
> decision of the evolution, since the change would have *limited users'=20
> valid choice* and *no replacement is provided*.
>
>
> What do rules of uncertainty, such as copy elision and unordered=20
> operations, usefully express besides optimization opportunities?
>
These rules are not all of uncertainty. It is *certainly **unspecified* (if=
=20
not undefined). It is obvious that users should not depend on the=20
particular unspecified behavior in a portable C++ program. Optimization is=
=20
nothing to do this principle.

Note that the "unsequenced" for evaluation itself is *not *about=20
uncertainty, but *indeterminancy*, which should be one of the key=20
characteristics of concurrent computation. (The actual wording is also=20
related to this property.) There even exist system for intended=20
*nondeterminism*.
=20

> If the optimization is of insignificant value, that would seem to imply=
=20
> that the rule is ripe for elimination.
>
> Not only significance. To change previously well-defined and clear rules,=
=20
you should have some valid reasons. You change them only when the reasons=
=20
are significant enough, or there would be cost in vain.

The optimization is valuable. Do the changes gives us more?
=20

> The analysis is similar for guaranteed copy elision, which has also been=
=20
> added to C++17: the language (i.e., its designers) never intended to=20
> express uncertainty, but only to run fast.
>
To allow programs running fast is a major goal of C++, but not the *only *o=
ne,=20
and not always the most important one.
=20

> Corner cases even exist where P0135R0 actually eliminates copy elision,=
=20
> but they are considered insignificant.
>
> This just show that there have been something come before the optimizatio=
n=20
purpose, *by design*.

And even if copy elision is eliminated in some cases, they do not harm the=
=20
result or goal of the optimization itself. No copy/move is generally more=
=20
efficient than a move. Note that there is rules depending on copy elision=
=20
(12.8/32 IIRC) which can "transform" a previously (in C++98/03 era) copy to=
=20
a move, but it is not able to transform a move to no-op. Note also the=20
rules are not making sure the result is more optimized: a move would be=20
equal to (or worse than, for an insane move constructor implementation) a=
=20
copy for several types. But they have already been semantically different.=
=20
The change for cases when optimization will not effect should also not be=
=20
accepted unconditionally.

The as-if rule isn=E2=80=99t a distinct rule at all, it=E2=80=99s just a cl=
arification of=20
> the fact that the standard only describes a distinct set of behaviors whe=
n=20
> a computer runs a program that was written in C++.
>
> No, the as-if rule and the remained rules are different in view of users,=
=20
because the former guarantees *no observable behavior would be changed* by=
=20
some usual transformation (by optimization) according to the rule. I treat=
=20
the remained as "exceptions", because they are special concerned with very=
=20
limited set of features and they are surprising to users. They are also=20
special because rare occur in other languages. In fact, ISO C has almost=20
the same rule about observable behavior equivalence (though without "as-if"=
=20
wording), but it has nothing about copy elision or merging of allocation=20
function calls (which can eliminate the potential side effects in debug=20
code), etc. (Think twice: why 'g++ -O0' does not turn off copy elision?)


=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=89 UTC+8=E4=B8=8B=E5=8D=8811:53:02=EF=BC=8CDavid Krauss=E5=86=99=E9=81=
=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word=
-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=931=
2=E2=80=9323, at 10:20 PM, FrankHB1989 &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"iVwESyRnDwAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">frank...@gmail.com</a>&gt; wrote:</=
div><br><div>For a high level language, there is one thing come before the =
optimization: expressiveness, which determines the possible interpretation =
of the code. Opportunity of optimization is granted by a few rules (the &qu=
ot;as-if&quot; rule and several other semantics exceptions like rules for c=
opy elision) based on the expressiveness. It will be lost if the new rules =
are strictly restrictive than before. (Any doubt?)<br><div><br>Whether it i=
s significant enough or not, is another story. The data would be good to il=
lustrate <b>this </b>significance, but far from the complete for decision o=
f the evolution, since the change would have <b>limited users&#39; valid ch=
oice</b> and <b>no replacement is provided</b>.<br></div></div></blockquote=
><div><br></div><div>What do rules of uncertainty, such as copy elision and=
 unordered operations, usefully express besides optimization opportunities?=
</div></div></div></blockquote><div>These rules are not all of uncertainty.=
 It is <i>certainly </i><b>unspecified</b>
 (if not undefined). It is obvious that users should not depend on the=20
particular unspecified behavior in a portable C++ program. Optimization=20
is nothing to do this principle.<br><br>Note that the &quot;unsequenced&quo=
t; for evaluation itself is <i>not </i>about uncertainty, but <b>indetermin=
ancy</b>, which should be one of the key characteristics of concurrent comp=
utation. (The actual wording is also related to this property.) There even =
exist system for intended <b>nondeterminism</b>.<br>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div>=
<div>If the optimization is of insignificant value, that would seem to impl=
y that the rule is ripe for elimination.</div><div><br></div></div></div></=
blockquote><div>Not only significance. To change previously well-defined an=
d clear rules, you should have some valid reasons. You change them only whe=
n the reasons are significant enough, or there would be cost in vain.<br><b=
r>The optimization is valuable. Do the changes gives us more?<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 style=3D"word-wrap:=
break-word"><div><div></div><div>The analysis is similar for guaranteed cop=
y elision, which has also been added to C++17: the language (i.e., its desi=
gners) never intended to express uncertainty, but only to run fast.</div></=
div></div></blockquote><div>To allow programs running fast is a major goal =
of C++, but not the <b>only </b>one, and not always the most important one.=
<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 style=3D"=
word-wrap:break-word"><div><div>Corner cases even exist where P0135R0 actua=
lly eliminates copy elision, but they are considered insignificant.</div></=
div><div><br></div></div></blockquote><div>This just show that there have b=
een something come before the optimization purpose, <i>by design</i>.<br><b=
r>And even if copy elision is eliminated in some cases, they do not harm th=
e result or goal of the optimization itself. No copy/move is generally more=
 efficient than a move. Note that there is rules depending on copy elision =
(12.8/32 IIRC) which can &quot;transform&quot; a previously (in C++98/03 er=
a) copy to a move, but it is not able to transform a move to no-op. Note al=
so the rules are not making sure the result is more optimized: a move would=
 be equal to (or worse than, for an insane move constructor implementation)=
 a copy for several types. But they have already been semantically differen=
t. The change for cases when optimization will not effect should also not b=
e accepted unconditionally.<br><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 style=3D"word-wrap:break-word"><div></div><div>The as-if ru=
le isn=E2=80=99t a distinct rule at all, it=E2=80=99s just a clarification =
of the fact that the standard only describes a distinct set of behaviors wh=
en a computer runs a program that was written in C++.</div><div><br></div><=
/div></blockquote><div>No, the as-if rule and the remained rules are differ=
ent in view of users, because the former guarantees <b>no observable behavi=
or would be changed</b> by some usual transformation (by optimization) acco=
rding to the rule. I treat the remained as &quot;exceptions&quot;, because =
they are special concerned with very limited set of features and they are s=
urprising to users. They are also special because rare occur in other langu=
ages. In fact, ISO C has almost the same rule about observable behavior equ=
ivalence (though without &quot;as-if&quot; wording), but it has nothing abo=
ut copy elision or merging of allocation function calls (which can eliminat=
e the potential side effects in debug code), etc. (Think twice: why &#39;g+=
+ -O0&#39; does not turn off copy elision?)<br><br><br>=C2=A0<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_105_226108060.1450940827000--
------=_Part_104_811519169.1450940826999--

.

--Apple-Mail=_AC828F96-09BB-4B45-8666-4A09D2E66EAC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9312=E2=80=9324, at 3:07 PM, FrankHB1989 <frankhb1989@gmail=
..com> wrote:
>=20
> These rules are not all of uncertainty. It is certainly unspecified (if n=
ot undefined). It is obvious that users should not depend on the particular=
 unspecified behavior in a portable C++ program. Optimization is nothing to=
 do this principle.
>=20
> Note that the "unsequenced" for evaluation itself is not about uncertaint=
y, but indeterminancy, which should be one of the key characteristics of co=
ncurrent computation. (The actual wording is also related to this property.=
) There even exist system for intended nondeterminism.

That connection between indeterminate order of evaluation and parallelism h=
as also crossed my mind. But, parallel programming technology is pretty adv=
anced <https://software.intel.com/en-us/articles/automatic-parallelization-=
with-intel-compilers>, and I trust the folks actively developing it to rais=
e their own objections. I suspect that the amount of parallelism inherent i=
n unordered subexpressions is too little to bother with, and exposing paral=
lelism already requires adding a means of expressing it (as OpenMP does) an=
d/or doing the heavy lifting to be able to get rid of semicolons.

=E2=80=9CObvious=E2=80=9D is a bit of a dirty word. Programmers should alwa=
ys write pure functions that don=E2=80=99t invalidate any pointers, or have=
 any other surprising side effects. In real life, programming is pretty tri=
cky.

> If the optimization is of insignificant value, that would seem to imply t=
hat the rule is ripe for elimination.
>=20
> Not only significance. To change previously well-defined and clear rules,=
 you should have some valid reasons. You change them only when the reasons =
are significant enough, or there would be cost in vain.
>=20
> The optimization is valuable. Do the changes gives us more?

The optimization is of unknown value because we have no data.

The gain in ease of portability and testing has been argued pretty convinci=
ngly.

Comparing ease of use against performance is apples and oranges, but ease o=
f use tends to promote correctness, which is usually held at higher priorit=
y.

> The analysis is similar for guaranteed copy elision, which has also been =
added to C++17: the language (i.e., its designers) never intended to expres=
s uncertainty, but only to run fast.
> To allow programs running fast is a major goal of C++, but not the only o=
ne, and not always the most important one.

Which side are you arguing, now? ;)

> Corner cases even exist where P0135R0 actually eliminates copy elision, b=
ut they are considered insignificant.
>=20
> This just show that there have been something come before the optimizatio=
n purpose, by design.

In that case, it=E2=80=99s just simplicity of the specification. Don=E2=80=
=99t know whether or not the corner case was considered in the design.

> The as-if rule isn=E2=80=99t a distinct rule at all, it=E2=80=99s just a =
clarification of the fact that the standard only describes a distinct set o=
f behaviors when a computer runs a program that was written in C++.
>=20
> No, the as-if rule and the remained rules are different in view of users,=
 because the former guarantees no observable behavior would be changed by s=
ome usual transformation (by optimization) according to the rule. I treat t=
he remained as "exceptions", because they are special concerned with very l=
imited set of features and they are surprising to users. They are also spec=
ial because rare occur in other languages. In fact, ISO C has almost the sa=
me rule about observable behavior equivalence (though without "as-if" wordi=
ng), but it has nothing about copy elision or merging of allocation functio=
n calls (which can eliminate the potential side effects in debug code), etc=
.. (Think twice: why 'g++ -O0' does not turn off copy elision?)

For ease of testing. IIRC it used to, but folks complained that the change =
in behavior made debugging more difficult.

What=E2=80=99s this about merging allocation function calls?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--Apple-Mail=_AC828F96-09BB-4B45-8666-4A09D2E66EAC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9312=
=E2=80=9324, at 3:07 PM, FrankHB1989 &lt;<a href=3D"mailto:frankhb1989@gmai=
l.com" class=3D"">frankhb1989@gmail.com</a>&gt; wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D"">These rules are not all of uncerta=
inty. It is <i class=3D"">certainly </i><b class=3D"">unspecified</b>
 (if not undefined). It is obvious that users should not depend on the=20
particular unspecified behavior in a portable C++ program. Optimization=20
is nothing to do this principle.<br class=3D""><div class=3D""><br class=3D=
"">Note that the "unsequenced" for evaluation itself is <i class=3D"">not <=
/i>about uncertainty, but <b class=3D"">indeterminancy</b>, which should be=
 one of the key characteristics of concurrent computation. (The actual word=
ing is also related to this property.) There even exist system for intended=
 <b class=3D"">nondeterminism</b>.<br class=3D""></div></div></blockquote><=
div><br class=3D""></div><div>That connection between indeterminate order o=
f evaluation and parallelism has also crossed my mind. But, parallel progra=
mming technology is&nbsp;<a href=3D"https://software.intel.com/en-us/articl=
es/automatic-parallelization-with-intel-compilers" class=3D"">pretty advanc=
ed</a>, and I trust the folks actively developing it to raise their own obj=
ections. I suspect that the amount of parallelism inherent in unordered sub=
expressions is too little to bother with, and exposing parallelism already =
requires adding a means of expressing it (as OpenMP does) and/or doing the =
heavy lifting to be able to get rid of semicolons.</div><div><br class=3D""=
></div><div>=E2=80=9CObvious=E2=80=9D is a bit of a dirty word. Programmers=
 should always write pure functions that don=E2=80=99t invalidate any point=
ers, or have any other surprising side effects. In real life, programming i=
s pretty tricky.</div><br class=3D""><blockquote type=3D"cite" class=3D""><=
div class=3D""><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"w=
ord-wrap:break-word" class=3D""><div class=3D""><div class=3D"">If the opti=
mization is of insignificant value, that would seem to imply that the rule =
is ripe for elimination.</div><div class=3D""><br class=3D""></div></div></=
div></blockquote><div class=3D"">Not only significance. To change previousl=
y well-defined and clear rules, you should have some valid reasons. You cha=
nge them only when the reasons are significant enough, or there would be co=
st in vain.<br class=3D""><br class=3D"">The optimization is valuable. Do t=
he changes gives us more?<br class=3D""></div></div></blockquote><div><br c=
lass=3D""></div><div>The optimization is of unknown value because we have n=
o data.</div><div><br class=3D""></div><div>The gain in ease of portability=
 and testing has been argued pretty convincingly.</div><div><br class=3D"">=
</div><div>Comparing ease of use against performance is apples and oranges,=
 but ease of use tends to promote correctness, which is usually held at hig=
her priority.</div><br class=3D""><blockquote type=3D"cite" class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word=
" class=3D""><div class=3D""><div class=3D"">The analysis is similar for gu=
aranteed copy elision, which has also been added to C++17: the language (i.=
e., its designers) never intended to express uncertainty, but only to run f=
ast.</div></div></div></blockquote><div class=3D"">To allow programs runnin=
g fast is a major goal of C++, but not the <b class=3D"">only </b>one, and =
not always the most important one.<br class=3D""></div></blockquote><div><b=
r class=3D""></div><div>Which side are you arguing, now? ;)</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div style=3D"word-wrap:break-word" class=3D""><div class=3D""=
><div class=3D"">Corner cases even exist where P0135R0 actually eliminates =
copy elision, but they are considered insignificant.</div></div><div class=
=3D""><br class=3D""></div></div></blockquote><div class=3D"">This just sho=
w that there have been something come before the optimization purpose, <i c=
lass=3D"">by design</i>.<br class=3D""></div></blockquote><div><br class=3D=
""></div><div>In that case, it=E2=80=99s just simplicity of the specificati=
on. Don=E2=80=99t know whether or not the corner case was considered in the=
 design.</div><br class=3D""><blockquote type=3D"cite" class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word" cla=
ss=3D""><div class=3D""></div><div class=3D"">The as-if rule isn=E2=80=99t =
a distinct rule at all, it=E2=80=99s just a clarification of the fact that =
the standard only describes a distinct set of behaviors when a computer run=
s a program that was written in C++.</div><div class=3D""><br class=3D""></=
div></div></blockquote><div class=3D"">No, the as-if rule and the remained =
rules are different in view of users, because the former guarantees <b clas=
s=3D"">no observable behavior would be changed</b> by some usual transforma=
tion (by optimization) according to the rule. I treat the remained as "exce=
ptions", because they are special concerned with very limited set of featur=
es and they are surprising to users. They are also special because rare occ=
ur in other languages. In fact, ISO C has almost the same rule about observ=
able behavior equivalence (though without "as-if" wording), but it has noth=
ing about copy elision or merging of allocation function calls (which can e=
liminate the potential side effects in debug code), etc. (Think twice: why =
'g++ -O0' does not turn off copy elision?)</div></blockquote></div><br clas=
s=3D""><div class=3D"">For ease of testing. IIRC it used to, but folks comp=
lained that the change in behavior made debugging more difficult.</div><div=
 class=3D""><br class=3D""></div><div class=3D"">What=E2=80=99s this about =
merging allocation function calls?</div><div class=3D""><br class=3D""></di=
v></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--Apple-Mail=_AC828F96-09BB-4B45-8666-4A09D2E66EAC--

.

------=_Part_2125_515045374.1450957629682
Content-Type: multipart/alternative;
 boundary="----=_Part_2126_135115967.1450957629682"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8B=E5=8D=884:10:26=EF=BC=8CDavid Krauss=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
> On 2015=E2=80=9312=E2=80=9324, at 3:07 PM, FrankHB1989 <frank...@gmail.co=
m <javascript:>>=20
> wrote:
>
> These rules are not all of uncertainty. It is *certainly **unspecified*=
=20
> (if not undefined). It is obvious that users should not depend on the=20
> particular unspecified behavior in a portable C++ program. Optimization i=
s=20
> nothing to do this principle.
>
> Note that the "unsequenced" for evaluation itself is *not *about=20
> uncertainty, but *indeterminancy*, which should be one of the key=20
> characteristics of concurrent computation. (The actual wording is also=20
> related to this property.) There even exist system for intended=20
> *nondeterminism*.
>
>
> That connection between indeterminate order of evaluation and parallelism=
=20
> has also crossed my mind. But, parallel programming technology is pretty=
=20
> advanced=20
> <https://software.intel.com/en-us/articles/automatic-parallelization-with=
-intel-compilers>,=20
> and I trust the folks actively developing it to raise their own objection=
s.=20
> I suspect that the amount of parallelism inherent in unordered=20
> subexpressions is too little to bother with, and exposing parallelism=20
> already requires adding a means of expressing it (as OpenMP does) and/or=
=20
> doing the heavy lifting to be able to get rid of semicolons.
>
> Concurrency is not parallelism.

=E2=80=9CObvious=E2=80=9D is a bit of a dirty word. Programmers should alwa=
ys write pure=20
> functions that don=E2=80=99t invalidate any pointers, or have any other s=
urprising=20
> side effects. In real life, programming is pretty tricky.
>
> If the optimization is of insignificant value, that would seem to imply=
=20
>> that the rule is ripe for elimination.
>>
>> Not only significance. To change previously well-defined and clear rules=
,=20
> you should have some valid reasons. You change them only when the reasons=
=20
> are significant enough, or there would be cost in vain.
>
> The optimization is valuable. Do the changes gives us more?
>
>
> The optimization is of unknown value because we have no data.
>
> No. The change *can* make reordering impossible, thus *may *harm=20
optimization. It can be proven with or without data.
=20

> The gain in ease of portability and testing has been argued pretty=20
> convincingly.
>
> I see no data about this.

The cost of training may be cheaper, but are you sure there is no (bad)=20
side effect? It sounds like we'd produce better programs by providing=20
possible more bug-to-bug compatibility ... there may be little damage since=
=20
they are already so unreliable enough?
=20

> Comparing ease of use against performance is apples and oranges, but ease=
=20
> of use tends to promote correctness, which is usually held at higher=20
> priority.
>
> Is that really correctness? Will it hide more related bugs? More risks or=
=20
less? I feel difficult to prove it or not this time.=20

> The analysis is similar for guaranteed copy elision, which has also been=
=20
>> added to C++17: the language (i.e., its designers) never intended to=20
>> express uncertainty, but only to run fast.
>>
> To allow programs running fast is a major goal of C++, but not the *only =
*one,=20
> and not always the most important one.
>
>
> Which side are you arguing, now? ;)
>
> My points do not changed. Optimization is good, but it is not just that=
=20
doubleplusgood - it has low precedence than expressiveness in general, esp.=
=20
when lack of data to makes it significant enough and indisputable. On the=
=20
other hand, lost of expressiveness caused by the change is certain. I never=
=20
thought the latter is insignificant in this case.

Optimization vs. expressiveness roughly reflect to two major aspects of=20
language design aimed to: possibility of high performance implementations=
=20
and expressive ability provided by abstraction. To a general-purposed=20
high-level language, both are important, but the latter is usually more=20
important, unless you can modify the design as frequent as you want (this=
=20
is just not the case of C++).

I am against the change of evaluation order, because it makes the language=
=20
worse in both aspects.

As ease of learning and reviewing defective code... I don't see how it=20
beneficial. I don't think it necessarily to attribute every difficulty to=
=20
the language itself. Remembering "use statements to keep order" is so easy=
=20
(at least easier than 'make_unique'). Even if finding the order is=20
difficult, finding the violation of this convention line by line should be=
=20
still easy for a human. I am surprised if any sane coders have difficulties=
=20
on it. Why the design of a language should change, due to the compromise to=
=20
some questionable learners, rather than the general requirements whose=20
existence is hardly to deny?

> Corner cases even exist where P0135R0 actually eliminates copy elision,=
=20
>> but they are considered insignificant.
>>
>> This just show that there have been something come before the=20
> optimization purpose, *by design*.
>
>
> In that case, it=E2=80=99s just simplicity of the specification. Don=E2=
=80=99t know=20
> whether or not the corner case was considered in the design.
>
> P0135R0 is different. I feel it is the right way. It may reflect the=20
"real" intent behind the usage better, with simpler rules to remember by=20
ordinary users (this is also contrast to the change about evaluation=20
rules). It specified that the contexts where elision must be performed, so=
=20
it is not only about "simplicity of the specification". Note not all=20
reasons are covered by example code in the proposal.

I don't find where P0135R0 fail to allow copy elision and the user cannot=
=20
to it (by force mandated copy elision) specifically.

BTW... the value category besides type systems is a mess. Historically the=
=20
design changes *a lot*:

   - In the B language, lvalues and rvalues are syntactic categories. Not=
=20
   many semantics rules for operands required. Well, there are no type=20
   systems. No conflict.
   - In C, lvalues are refined by semantics rules. Rvalues are merged=20
   within values. C has a type system, but the lvalueness is out of the sco=
pe.=20
   The bad news is object types and lvalues may confuse a lot of people.=20
   - After const qualifier introduced to C, things get significantly worse.=
=20
   Const-qualified and modifiable lvalues... WTF? Any redundancy?
   - C++ ...boom. Why values of references and lvalues are different? (IIRC=
=20
   the earliest public available paper on WG21 website is about this topic.=
...)
   - Note that in C, only lvalues can have qualifiers. In C++, things get=
=20
   significantly worse, since you'd consider class type rvalues with=20
   qualifiers. And arrays...(I don't remember the DR number.)
   - Move semantics ... Ok, rvalue references. But value category can not=
=20
   hold them well. So, xvalues, glvalues, prvalues... (I don't remember the=
=20
   document number.)
   - Wait, what about xvalues of function type?
   - ...
  =20
Is there can be a whole graceful design on it? I don't know. Basically I am=
=20
not surprised that someone will change the rules again ...

> The as-if rule isn=E2=80=99t a distinct rule at all, it=E2=80=99s just a =
clarification of=20
>> the fact that the standard only describes a distinct set of behaviors wh=
en=20
>> a computer runs a program that was written in C++.
>>
>> No, the as-if rule and the remained rules are different in view of users=
,=20
> because the former guarantees *no observable behavior would be changed*=
=20
> by some usual transformation (by optimization) according to the rule. I=
=20
> treat the remained as "exceptions", because they are special concerned wi=
th=20
> very limited set of features and they are surprising to users. They are=
=20
> also special because rare occur in other languages. In fact, ISO C has=20
> almost the same rule about observable behavior equivalence (though withou=
t=20
> "as-if" wording), but it has nothing about copy elision or merging of=20
> allocation function calls (which can eliminate the potential side effects=
=20
> in debug code), etc. (Think twice: why 'g++ -O0' does not turn off copy=
=20
> elision?)
>
>
> For ease of testing. IIRC it used to, but folks complained that the chang=
e=20
> in behavior made debugging more difficult.
>
>  Yes, that's it: change of the observable behavior is often not expected=
=20
by ordinary users. This is tricky comparing to the traditional as-if rule.

What=E2=80=99s this about merging allocation function calls?
>
> It seems a new feature in C++14, in [expr.new]/10. I find it by read the=
=20
working draft (and by the way, fixed an editorial issue in the example),=20
and the intent is "obvious", so I did not go to find the original proposal.
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8B=E5=8D=884:10:26=EF=BC=8CDavid Krauss=E5=86=99=E9=81=
=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word=
-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=931=
2=E2=80=9324, at 3:07 PM, FrankHB1989 &lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"qK4-gHqcDwAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">frank...@gmail.com</a>&gt; wrote:</d=
iv><br><div>These rules are not all of uncertainty. It is <i>certainly </i>=
<b>unspecified</b>
 (if not undefined). It is obvious that users should not depend on the=20
particular unspecified behavior in a portable C++ program. Optimization=20
is nothing to do this principle.<br><div><br>Note that the &quot;unsequence=
d&quot; for evaluation itself is <i>not </i>about uncertainty, but <b>indet=
erminancy</b>, which should be one of the key characteristics of concurrent=
 computation. (The actual wording is also related to this property.) There =
even exist system for intended <b>nondeterminism</b>.<br></div></div></bloc=
kquote><div><br></div><div>That connection between indeterminate order of e=
valuation and parallelism has also crossed my mind. But, parallel programmi=
ng technology is=C2=A0<a href=3D"https://software.intel.com/en-us/articles/=
automatic-parallelization-with-intel-compilers" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75http=
s%3A%2F%2Fsoftware.intel.com%2Fen-us%2Farticles%2Fautomatic-parallelization=
-with-intel-compilers\46sa\75D\46sntz\0751\46usg\75AFQjCNHLgi7fycHme6AH0zG8=
3mHGIUf3_w&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\75https%3A%2F%2Fsoftware.intel.com%2Fen-us%2Farticles%2Fautomat=
ic-parallelization-with-intel-compilers\46sa\75D\46sntz\0751\46usg\75AFQjCN=
HLgi7fycHme6AH0zG83mHGIUf3_w&#39;;return true;">pretty advanced</a>, and I =
trust the folks actively developing it to raise their own objections. I sus=
pect that the amount of parallelism inherent in unordered subexpressions is=
 too little to bother with, and exposing parallelism already requires addin=
g a means of expressing it (as OpenMP does) and/or doing the heavy lifting =
to be able to get rid of semicolons.</div><div><br></div></div></div></bloc=
kquote><div>Concurrency is not parallelism.<br><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 style=3D"word-wrap:break-word"><div><div><=
/div><div>=E2=80=9CObvious=E2=80=9D is a bit of a dirty word. Programmers s=
hould always write pure functions that don=E2=80=99t invalidate any pointer=
s, or have any other surprising side effects. In real life, programming is =
pretty tricky.</div><br><blockquote type=3D"cite"><div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><div>If the op=
timization is of insignificant value, that would seem to imply that the rul=
e is ripe for elimination.</div><div><br></div></div></div></blockquote><di=
v>Not only significance. To change previously well-defined and clear rules,=
 you should have some valid reasons. You change them only when the reasons =
are significant enough, or there would be cost in vain.<br><br>The optimiza=
tion is valuable. Do the changes gives us more?<br></div></div></blockquote=
><div><br></div><div>The optimization is of unknown value because we have n=
o data.</div><div><br></div></div></div></blockquote><div>No. The change <i=
>can</i> make reordering impossible, thus <i>may </i>harm optimization. It =
can be proven with or without data.<br>=C2=A0<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 style=3D"word-wrap:break-word"><div><div></di=
v><div>The gain in ease of portability and testing has been argued pretty c=
onvincingly.</div><div><br></div></div></div></blockquote><div>I see no dat=
a about this.<br><br>The cost of training may be cheaper, but are you sure =
there is no (bad) side effect? It sounds like we&#39;d produce better progr=
ams by providing possible more bug-to-bug compatibility ... there may be li=
ttle damage since they are already so unreliable enough?<br>=C2=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break=
-word"><div><div></div><div>Comparing ease of use against performance is ap=
ples and oranges, but ease of use tends to promote correctness, which is us=
ually held at higher priority.</div><br></div></div></blockquote><div>Is th=
at really correctness? Will it hide more related bugs? More risks or less? =
I feel difficult to prove it or not this time. <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 style=3D"word-wrap:break-word"><div><block=
quote type=3D"cite"><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"w=
ord-wrap:break-word"><div><div>The analysis is similar for guaranteed copy =
elision, which has also been added to C++17: the language (i.e., its design=
ers) never intended to express uncertainty, but only to run fast.</div></di=
v></div></blockquote><div>To allow programs running fast is a major goal of=
 C++, but not the <b>only </b>one, and not always the most important one.<b=
r></div></blockquote><div><br></div><div>Which side are you arguing, now? ;=
)</div><br></div></div></blockquote><div>My points do not changed. Optimiza=
tion is good, but it is not just that doubleplusgood - it has low precedenc=
e than expressiveness in general, esp. when lack of data to makes it signif=
icant enough and indisputable. On the other hand, lost of expressiveness ca=
used by the change is certain. I never thought the latter is insignificant =
in this case.<br><br>Optimization vs. expressiveness roughly reflect to two=
 major aspects of language design aimed to: possibility of high performance=
 implementations and expressive ability provided by abstraction. To a gener=
al-purposed high-level language, both are important, but the latter is  usu=
ally more important, unless you can modify the design as frequent as you wa=
nt (this is just not the case of C++).<br><br>I am against the change of ev=
aluation order, because it makes the language worse in both aspects.<br><br=
>As ease of learning and reviewing defective code... I don&#39;t see how it=
 beneficial. I don&#39;t think it necessarily to attribute every difficulty=
 to the language itself. Remembering &quot;use statements to keep order&quo=
t; is so easy (at least easier than &#39;make_unique&#39;). Even if finding=
 the order is difficult, finding the violation of this convention line by l=
ine should be still easy for a human. I am surprised if any sane coders hav=
e difficulties on it. Why the design of a language should change, due=20
to the compromise to some questionable learners, rather than=20
the general requirements whose existence is hardly to deny?<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 style=3D"word-wrap:break-word">=
<div><blockquote type=3D"cite"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 style=3D"word-wrap:break-word"><div><div>Corner cases even exist where P01=
35R0 actually eliminates copy elision, but they are considered insignifican=
t.</div></div><div><br></div></div></blockquote><div>This just show that th=
ere have been something come before the optimization purpose, <i>by design<=
/i>.<br></div></blockquote><div><br></div><div>In that case, it=E2=80=99s j=
ust simplicity of the specification. Don=E2=80=99t know whether or not the =
corner case was considered in the design.</div><br></div></div></blockquote=
><div>P0135R0 is different. I feel it is the right way. It may reflect the =
&quot;real&quot; intent behind the usage better, with simpler rules to reme=
mber by ordinary users (this is also contrast to the change about evaluatio=
n rules). It specified that the contexts where elision must be performed, s=
o it is not only about &quot;simplicity of the specification&quot;. Note no=
t all reasons are covered by example code in the proposal.<br><br>I don&#39=
;t find where P0135R0 fail to allow copy elision and the user cannot to it =
(by force mandated copy elision) specifically.<br><br>BTW... the value cate=
gory besides type systems is a mess. Historically the design changes <b>a l=
ot</b>:<br><ul><li>In the B language, lvalues and rvalues are syntactic cat=
egories. Not many semantics rules for operands required. Well, there are no=
 type systems. No conflict.<br></li><li>In C, lvalues are refined by semant=
ics rules. Rvalues are merged within values. C has a type system, but the l=
valueness is out of the scope. The bad news is object types and lvalues may=
 confuse a lot of people. <br></li><li>After const qualifier introduced to =
C, things get significantly worse. Const-qualified and modifiable lvalues..=
.. WTF? Any redundancy?<br></li><li>C++ ...boom. Why values of references an=
d lvalues are different? (IIRC the earliest public available paper on WG21 =
website is about this topic...)</li><li>Note that in C, only lvalues can ha=
ve qualifiers. In C++, things get significantly worse, since you&#39;d cons=
ider class type rvalues with qualifiers. And arrays...(I don&#39;t remember=
 the DR number.)</li><li>Move semantics ... Ok, rvalue references. But valu=
e category can not hold them well. So, xvalues, glvalues, prvalues... (I do=
n&#39;t remember the document number.)</li><li>Wait, what about  xvalues of=
 function type?</li><li>...<br></li></ul>Is there can be a whole graceful d=
esign on it? I don&#39;t know. Basically I am not surprised that someone wi=
ll change the rules again ...<br></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 style=3D"word-wrap:break-word"><div><blockquote type=3D"cite"=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word=
"><div></div><div>The as-if rule isn=E2=80=99t a distinct rule at all, it=
=E2=80=99s just a clarification of the fact that the standard only describe=
s a distinct set of behaviors when a computer runs a program that was writt=
en in C++.</div><div><br></div></div></blockquote><div>No, the as-if rule a=
nd the remained rules are different in view of users, because the former gu=
arantees <b>no observable behavior would be changed</b> by some usual trans=
formation (by optimization) according to the rule. I treat the remained as =
&quot;exceptions&quot;, because they are special concerned with very limite=
d set of features and they are surprising to users. They are also special b=
ecause rare occur in other languages. In fact, ISO C has almost the same ru=
le about observable behavior equivalence (though without &quot;as-if&quot; =
wording), but it has nothing about copy elision or merging of allocation fu=
nction calls (which can eliminate the potential side effects in debug code)=
, etc. (Think twice: why &#39;g++ -O0&#39; does not turn off copy elision?)=
</div></blockquote></div><br><div>For ease of testing. IIRC it used to, but=
 folks complained that the change in behavior made debugging more difficult=
..</div><div><br></div></div></blockquote><div>=C2=A0Yes, that&#39;s it: cha=
nge of the observable behavior is often not expected by ordinary users. Thi=
s is tricky comparing to the traditional as-if rule.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><di=
v></div><div>What=E2=80=99s this about merging allocation function calls?</=
div><div><br></div></div></blockquote><div>It seems a new feature in C++14,=
 in [expr.new]/10. I find it by read the working draft (and by the way, fix=
ed an editorial issue in the example), and the intent is &quot;obvious&quot=
;, so I did not go to find the original proposal.<br>=C2=A0<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_2126_135115967.1450957629682--
------=_Part_2125_515045374.1450957629682--

.

This is a multi-part message in MIME format.
--------------010701080005000806060604
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 24.12.2015 um 12:47 schrieb FrankHB1989:
>
>     The optimization is of unknown value because we have no data.
>
> No. The change /can/ make reordering impossible, thus /may /harm
> optimization. It can be proven with or without data.
>
>
Well then provide a proof and silence this debate once and for all.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--------------010701080005000806060604
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 24.12.2015 um 12:47 schrieb FrankHB1989:<br>
    <blockquote
      cite=3D"mid:91b4ffd7-dfc4-4a3e-a92d-e48c4459f57a@isocpp.org"
      type=3D"cite">
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div style=3D"word-wrap:break-word">
          <div>The optimization is of unknown value because we have no
            data.
            <div><br>
            </div>
          </div>
        </div>
      </blockquote>
      <div>No. The change <i>can</i> make reordering impossible, thus <i>ma=
y
        </i>harm optimization. It can be proven with or without data.<br>
        =C2=A0<br>
      </div>
      <br>
    </blockquote>
    Well then provide a proof and silence this debate once and for all.<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------010701080005000806060604--

.

--089e0122eda4b4e5d60527a3a12e
Content-Type: text/plain; charset=UTF-8

On Wed, Dec 23, 2015 at 3:25 AM, <michi.henning@canonical.com> wrote:

> If I am *that* desperate to squeeze that last ounce on performance, I
> should probably be writing assembly anyway.
>

Assembly is opaque to the optimizer so harms performance of surrounding
code. And you can't write assembly for template code, nor target multiple
instruction sets.


> I certainly shouldn't be relying on an optimiser getting me over the line
> by being clever with evaluation order because the optimiser can change its
> behaviour at any time, and optimisers for different compilers may do it
> differently.
>

Which is why when upgrading the compiler you run regression tests and fully
investigate any behavioral or performance 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0122eda4b4e5d60527a3a12e
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, Dec 23, 2015 at 3:25 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:michi=
..henning@canonical.com" target=3D"_blank">michi.henning@canonical.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"><div>If=
 I am *that* desperate to squeeze that last ounce on performance, I should =
probably be writing assembly anyway.</div></div></blockquote><div><br></div=
><div>Assembly is opaque to the optimizer so harms performance of surroundi=
ng code. And you can&#39;t write assembly for template code, nor target mul=
tiple instruction sets.</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 dir=3D"ltr"><div> I certainly shouldn&#39;t be relying on an optimis=
er getting me over the line by being clever with evaluation order because t=
he optimiser can change its behaviour at any time, and optimisers for diffe=
rent compilers may do it differently.</div></div></blockquote><div><br></di=
v><div>Which is why when upgrading the compiler you run regression tests an=
d fully investigate any behavioral or performance changes.</div></div></div=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e0122eda4b4e5d60527a3a12e--

.

------=_Part_2157_963109892.1450960029887
Content-Type: multipart/alternative;
 boundary="----=_Part_2158_1089583111.1450960029887"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8B=E5=8D=887:52:39=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 24.12.2015 um 12:47 schrieb FrankHB1989:
>
> The optimization is of unknown value because we have no data.=20
>>
>> No. The change *can* make reordering impossible, thus *may *harm=20
> optimization. It can be proven with or without data.
> =20
>
> Well then provide a proof and silence this debate once and for all.
>

Proof to what? The former half is implied by "left-to-right" literally.

The second half... So as I have written: "any doubt"? Do you mean you=20
believe that not allowing reordering of evaluation will *always *have no=20
effect on optimization?

I am sure this will not silence this debate because this is not the 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=
=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=887:52:39=EF=BC=8CMiro Knejp=
=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;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    Am 24.12.2015 um 12:47 schrieb FrankHB1989:<br>
    <blockquote type=3D"cite">
      <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
        <div style=3D"word-wrap:break-word">
          <div>The optimization is of unknown value because we have no
            data.
            <div><br>
            </div>
          </div>
        </div>
      </blockquote>
      <div>No. The change <i>can</i> make reordering impossible, thus <i>ma=
y
        </i>harm optimization. It can be proven with or without data.<br>
        =C2=A0<br>
      </div>
      <br>
    </blockquote>
    Well then provide a proof and silence this debate once and for all.<br>=
</div></blockquote><div><br>Proof to what? The former half is implied by &q=
uot;left-to-right&quot; literally.<br><br>The second half... So as I have w=
ritten: &quot;any doubt&quot;? Do you mean you believe that not allowing re=
ordering of evaluation will <i>always </i>have no effect on optimization?<b=
r><br>I am sure this will not silence this debate because this is not the p=
oint.<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_2158_1089583111.1450960029887--
------=_Part_2157_963109892.1450960029887--

.

On Wednesday 23 December 2015 17:57:28 jgottman6@gmail.com wrote:
>  This code seems perfectly reasonable at first glance; new is called and
> the result is immediately given to shared_ptr's constructor.  But as Scott
> Meyers shows in "Effective Modern C++", if the order of evaluation of the
> subexpressions is
> 1) new int(7)
> 2) bar()
> 3) shared_ptr constructor
>
> and bar() throws an exception, this code can leak.   I don't think it is
> reasonable to force users to have to defend against cases like this.

None of the proposals in this mailing list would defend against that since
we're talking about left-to-right evaluation. The order would remain as above,
which means bar() needs to be noexcept.

Unless someone is proposing right-to-left evaluation of function arguments. If
so, I'd recommend relaxing it to implementation-defined, so that the order is
given by ABI:

  void __pascal fp(int a, int b, int c);
  void __cdecl fc(int a, int b, int c);

  fp(f(), g(), h());  // order: f(), g(), h()
  fc(f(), g(), h()); // order: h(), g(), f()
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

This is a multi-part message in MIME format.
--------------020102040304020502050400
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 24.12.2015 um 13:27 schrieb FrankHB1989:
>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B =
UTC+8=E4=B8=8B=E5=8D=887:52:39=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=
=9A
>
>     Am 24.12.2015 um 12:47 schrieb FrankHB1989:
>>
>>         The optimization is of unknown value because we have no data.
>>
>>     No. The change /can/ make reordering impossible, thus /may /harm
>>     optimization. It can be proven with or without data.
>>
>>
>     Well then provide a proof and silence this debate once and for all.
>
>
> Proof to what? The former half is implied by "left-to-right" literally.
>
> The second half... So as I have written: "any doubt"? Do you mean you=20
> believe that not allowing reordering of evaluation will /always /have=20
> no effect on optimization?
It doesn't matter what I believe. You said it "can be proven with or=20
without data". Well then do so. Provide a proof, hand it in to the=20
committee, and then we finally have a basis for discussion. Up until now=20
all we have is anecdotes and speculation. If you say your position can=20
be proven, prove it. Just postulating something can be proven is=20
meaningless without demonstrating the actual proof.
>
> I am sure this will not silence this debate because this is not the point=
..
Then what is the point? If you're not trying to prevent the proposal=20
from happening, why waste your time arguing against it? If you know how=20
to prove the paper to be wrong or a bad idea I am certain the authors=20
and committee members alike are very interested to hear 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--------------020102040304020502050400
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 24.12.2015 um 13:27 schrieb FrankHB1989:<br>
    <blockquote
      cite=3D"mid:1314492f-f073-485a-8d61-bc8a06ffaf72@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8B=E5=8D=887:52:39=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;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000"> Am 24.12.2015 um 12:47
            schrieb FrankHB1989:<br>
            <blockquote type=3D"cite">
              <blockquote class=3D"gmail_quote"
                style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                solid;padding-left:1ex">
                <div style=3D"word-wrap:break-word">
                  <div>The optimization is of unknown value because we
                    have no data.
                    <div><br>
                    </div>
                  </div>
                </div>
              </blockquote>
              <div>No. The change <i>can</i> make reordering
                impossible, thus <i>may </i>harm optimization. It can
                be proven with or without data.<br>
                =C2=A0<br>
              </div>
              <br>
            </blockquote>
            Well then provide a proof and silence this debate once and
            for all.<br>
          </div>
        </blockquote>
        <div><br>
          Proof to what? The former half is implied by "left-to-right"
          literally.<br>
          <br>
          The second half... So as I have written: "any doubt"? Do you
          mean you believe that not allowing reordering of evaluation
          will <i>always </i>have no effect on optimization?<br>
        </div>
      </div>
    </blockquote>
    It doesn't matter what I believe. You said it "can be proven with or
    without data". Well then do so. Provide a proof, hand it in to the
    committee, and then we finally have a basis for discussion. Up until
    now all we have is anecdotes and speculation. If you say your
    position can be proven, prove it. Just postulating something can be
    proven is meaningless without demonstrating the actual proof.<br>
    <blockquote
      cite=3D"mid:1314492f-f073-485a-8d61-bc8a06ffaf72@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          I am sure this will not silence this debate because this is
          not the point.<br>
        </div>
      </div>
    </blockquote>
    Then what is the point? If you're not trying to prevent the proposal
    from happening, why waste your time arguing against it? If you know
    how to prove the paper to be wrong or a bad idea I am certain the
    authors and committee members alike are very interested to hear it.<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------020102040304020502050400--

.

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

On 24 Dec 2015 13:22, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> Am 24.12.2015 um 13:27 schrieb FrankHB1989:
>>
>>
>>
>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B=
 UTC+8=E4=B8=8B=E5=8D=887:52:39=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> Am 24.12.2015 um 12:47 schrieb FrankHB1989:
>>>>>
>>>>> The optimization is of unknown value because we have no data.
>>>>>
>>>> No. The change can make reordering impossible, thus may harm
optimization. It can be proven with or without data.
>>>>
>>>>
>>> Well then provide a proof and silence this debate once and for all.
>>
>>
>> Proof to what? The former half is implied by "left-to-right" literally.
>>
>> The second half... So as I have written: "any doubt"? Do you mean you
believe that not allowing reordering of evaluation will always have no
effect on optimization?
>
> It doesn't matter what I believe. You said it "can be proven with or
without data". Well then do so. Provide a proof, hand it in to the
committee, and then we finally have a basis for discussion. Up until now
all we have is anecdotes and speculation. If you say your position can be
proven, prove it. Just postulating something can be proven is meaningless
without demonstrating the actual proof.

This discussion started with a sketch of an existence proof, which has
since been made concrete - and with real code, not just a contrived
example. What more do you want?

>>
>> I am sure this will not silence this debate because this is not the
point.
>
> Then what is the point? If you're not trying to prevent the proposal from
happening, why waste your time arguing against it? If you know how to prove
the paper to be wrong or a bad idea I am certain the authors and committee
members alike are very interested to hear it.
>

If this discussion could be silenced by a proof, it would have ended weeks
ago. The point appears to be to demonstrate how much certain people value
an imagined increase in safety over a very real cost in expressiveness and
performance.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<p dir=3D"ltr"><br>
On 24 Dec 2015 13:22, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.kne=
jp@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Am 24.12.2015 um 13:27 schrieb FrankHB1989:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8B=E5=8D=887:52:39=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=
=EF=BC=9A<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Am 24.12.2015 um 12:47 schrieb FrankHB1989:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; The optimization is of unknown value because we have n=
o data.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; No. The change can make reordering impossible, thus may ha=
rm optimization. It can be proven with or without data.<br>
&gt;&gt;&gt;&gt; =C2=A0<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt; Well then provide a proof and silence this debate once and for=
 all.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Proof to what? The former half is implied by &quot;left-to-right&q=
uot; literally.<br>
&gt;&gt;<br>
&gt;&gt; The second half... So as I have written: &quot;any doubt&quot;? Do=
 you mean you believe that not allowing reordering of evaluation will alway=
s have no effect on optimization?<br>
&gt;<br>
&gt; It doesn&#39;t matter what I believe. You said it &quot;can be proven =
with or without data&quot;. Well then do so. Provide a proof, hand it in to=
 the committee, and then we finally have a basis for discussion. Up until n=
ow all we have is anecdotes and speculation. If you say your position can b=
e proven, prove it. Just postulating something can be proven is meaningless=
 without demonstrating the actual proof.</p>
<p dir=3D"ltr">This discussion started with a sketch of an existence proof,=
 which has since been made concrete - and with real code, not just a contri=
ved example. What more do you want? </p>
<p dir=3D"ltr">&gt;&gt;<br>
&gt;&gt; I am sure this will not silence this debate because this is not th=
e point.<br>
&gt;<br>
&gt; Then what is the point? If you&#39;re not trying to prevent the propos=
al from happening, why waste your time arguing against it? If you know how =
to prove the paper to be wrong or a bad idea I am certain the authors and c=
ommittee members alike are very interested to hear it.<br>
&gt;</p>
<p dir=3D"ltr">If this discussion could be silenced by a proof, it would ha=
ve ended weeks ago. The point appears to be to demonstrate how much certain=
 people value an imagined increase in safety over a very real cost in expre=
ssiveness and performance. </p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1140f6243d816b0527a5027c--

.

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

On Thu, Dec 24, 2015 at 12:01 AM, Hyman Rosen <hyman.rosen@gmail.com> wrote=
:

> A programming language is a means for a programmer to instruct a computer
> to carry out a computation.  If the meaning of a program is sufficiently
> underspecified such that the computer can carry out a variety of
> computations with different effects, this leads to serious possibility of
> error in the case where the programmer did not realize that some
> interpretation was possible and the one chosen by the implementation was
> the one that the programmer expected, because at some point in the future=
,
> the implementation may choose the unwelcome interpretation.
>

Every C++ program is underspecified by that definition; the only way to
fully specify behavior is to write in assembly and run on the bare metal.
There is a trade-off between expressiveness, performance, and possibility
of error.

Code review is no answer - the questionable constructs do not have to be
> clever.  Consider the Qt expression previously posted:
>
> textLayout()->nextCursorPosition(m_cursor) - m_cursor
>
> To fail code review, a reviewer must realize that nextCursorPosition can
> modify m_cursor and that therefore the two uses of it in the expression
> might not have the same value, and that it's legitimate for the
> implementation to interpret this in two different ways.  Guaranteed, this
> will be missed much of the time.  It is therefore necessary that such
> constructs have only a single interpretation, in which case it will match
> the programmer's expectation now and forever, or it will not and the
> programmer will fix it.
>

Why should this fail code review? If nextCursorPosition modifies m_cursor,
that's a bug in nextCursorPosition, not in the posted code.

If it is intended that m_cursor be modified between the two occurrences in
the above code, then even if the language were modified to reload m_cursor,
it would still not be apparent from reading the expression, so it would
have to be rewritten anyway:

auto const nextPosition =3D textLayout()->nextCursorPosition(m_cursor);
// NOTE: nextCursorPosition may have modified m_cursor
nextPosition - m_cursor // ...

If it is desirable to have the implementation pick from a set of possible
> interpretations then the programming language should provide a way of
> saying so explicitly, so that readers of the program can see this clearly=
..
>

That would be fine if we were designing a language from scratch. But we
already have syntax to explicitly order evaluations where desired; you're
asking to repurpose syntax that currently means unspecified ordered or
unordered evaluation to have mean evaluation in a specific order, wasting
that syntax and changing the meaning of existing code, which would have to
be rewritten to use whatever new syntax designating unordered evaluation
were created; it would also create uncertainty around the meaning of code
subsequently written. That's a huge burden, and for a comparatively
minuscule benefit.


> We should not ask programmers to =E2=80=9Cdon=E2=80=99t modify a variable=
 and also use it
> within the same line=E2=80=9D any more than we ask them to "don't call tw=
o
> functions within the same line".  The reason we have the former rule is
> that our programming languages have bad specifications.  The notion that =
we
> can work around this by telling programmers not to be clever is dead wron=
g
> - the problem occurs when programmers do not realize that they have been
> clever, and just think they have written code with one meaning.
>

We should absolutely ask the former, because it is essential to
comprehensible and maintainable code. Whether or not programmers appreciate
that they are being clever is immaterial if they can appreciate the
difference between unclear and clear 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

--001a1140c20c2b35160527a57d9f
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, Dec 24, 2015 at 12:01 AM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"=
mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@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">A programming languag=
e is a means for a programmer to instruct a computer to carry out a computa=
tion.=C2=A0 If the meaning of a program is sufficiently underspecified such=
 that the computer can carry out a variety of computations with different e=
ffects, this leads to serious possibility of error in the case where the pr=
ogrammer did not realize that some interpretation was possible and the one =
chosen by the implementation was the one that the programmer expected, beca=
use at some point in the future, the implementation may choose the unwelcom=
e interpretation.</div></blockquote><div><br></div><div>Every C++ program i=
s underspecified by that definition; the only way to fully specify behavior=
 is to write in assembly and run on the bare metal. There is a trade-off be=
tween expressiveness, performance, and possibility of error.=C2=A0</div><di=
v><br></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></div><div>Code review i=
s no answer - the questionable constructs do not have to be clever.=C2=A0 C=
onsider the Qt expression previously posted:<blockquote type=3D"cite" style=
=3D"color:rgb(80,0,80);font-size:12.8px"><div dir=3D"ltr"><div class=3D"gma=
il_quote"><table><tbody><tr><td style=3D"font-family:Consolas,&#39;Liberati=
on Mono&#39;,Menlo,Courier,monospace;padding:0px 10px;vertical-align:top;fo=
nt-size:12px;white-space:pre-wrap;overflow:visible;word-wrap:normal;backgro=
und-color:rgb(248,238,199)"><span style=3D"color:rgb(0,134,179)">textLayout=
</span>()-&gt;<span style=3D"color:rgb(0,134,179)">nextCursorPosition</span=
>(m_cursor) - m_cursor</td></tr></tbody></table></div></div></blockquote>To=
 fail code review, a reviewer must realize that nextCursorPosition can modi=
fy m_cursor and that therefore the two uses of it in the expression might n=
ot have the same value, and that it&#39;s legitimate for the implementation=
 to interpret this in two different ways.=C2=A0 Guaranteed, this will be mi=
ssed much of the time.=C2=A0 It is therefore necessary that such constructs=
 have only a single interpretation, in which case it will match the program=
mer&#39;s expectation now and forever, or it will not and the programmer wi=
ll fix it.<br></div></div></blockquote><div><br></div><div>Why should this =
fail code review? If nextCursorPosition modifies m_cursor, that&#39;s a bug=
 in nextCursorPosition, not in the posted code.</div><div><br></div><div>If=
 it is intended that m_cursor be modified between the two occurrences in th=
e above code, then even if the language were modified to reload m_cursor, i=
t would still not be apparent from reading the expression, so it would have=
 to be rewritten anyway:</div><div><br></div><font face=3D"monospace, monos=
pace">auto const nextPosition =3D textLayout()-&gt;nextCursorPosition(m_cur=
sor);</font></div><div class=3D"gmail_quote"><font face=3D"monospace, monos=
pace">// NOTE: nextCursorPosition may have modified m_cursor</font></div><d=
iv class=3D"gmail_quote"><font face=3D"monospace, monospace">nextPosition -=
 m_cursor // ...</font></div><div class=3D"gmail_quote"><br></div><div clas=
s=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"><div dir=3D"ltr"><div>If it is desirable=
 to have the implementation pick from a set of possible interpretations the=
n the programming language should provide a way of saying so explicitly, so=
 that readers of the program can see this clearly.<br></div></div></blockqu=
ote><div><br></div><div>That would be fine if we were designing a language =
from scratch. But we already have syntax to explicitly order evaluations wh=
ere desired; you&#39;re asking to repurpose syntax that currently means uns=
pecified ordered or unordered evaluation to have mean evaluation in a speci=
fic order, wasting that syntax and changing the meaning of existing code, w=
hich would have to be rewritten to use whatever new syntax designating unor=
dered evaluation were created; it would also create uncertainty around the =
meaning of code subsequently written. That&#39;s a huge burden, and for a c=
omparatively minuscule benefit.</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>We should not ask programmers to <span style=3D"font-size=
:12.8px">=E2=80=9Cdon=E2=80=99t modify a variable and also use it within th=
e same line=E2=80=9D any more than we ask them to &quot;don&#39;t call two =
functions within the same line&quot;.=C2=A0 The reason we have the former r=
ule is that our programming languages have bad specifications.=C2=A0 The no=
tion that we can work around this by telling programmers not to be clever i=
s dead wrong - the problem occurs when programmers do not realize that they=
 have been clever, and just think they have written code with one meaning.<=
/span></div></div></blockquote><div><br></div><div>We should absolutely ask=
 the former, because it is essential to comprehensible and maintainable cod=
e. Whether or not programmers appreciate that they are being clever is imma=
terial if they can appreciate the difference between unclear and clear styl=
es.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1140c20c2b35160527a57d9f--

.

--047d7bd75cb08eace20527a5951e
Content-Type: text/plain; charset=UTF-8

On Thu, Dec 24, 2015 at 1:57 AM, <jgottman6@gmail.com> wrote:

> It's not just overly clever code that can be bitten by the
> order-of-evaluation bug.  Consider the code
> foo(shared_ptr<int>(new int(7)), bar());
>
>  This code seems perfectly reasonable at first glance; new is called and
> the result is immediately given to shared_ptr's constructor.  But as Scott
> Meyers shows in "Effective Modern C++", if the order of evaluation of the
> subexpressions is
> 1) new int(7)
> 2) bar()
> 3) shared_ptr constructor
>
> and bar() throws an exception, this code can leak.   I don't think it is
> reasonable to force users to have to defend against cases like this.
>

If you're using legacy APIs that produce unmanaged resources, it seems
perfectly reasonable to expect users to encapsulate those calls; that's
just good style.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bd75cb08eace20527a5951e
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, Dec 24, 2015 at 1:57 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:jgott=
man6@gmail.com" target=3D"_blank">jgottman6@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div>It&#39;s not just overly clever cod=
e that can be bitten by the order-of-evaluation bug.=C2=A0 Consider the cod=
e<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,1=
87,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><di=
v><span style=3D"color:#000">foo</span><span style=3D"color:#660">(</span><=
span style=3D"color:#000">shared_ptr</span><span style=3D"color:#080">&lt;i=
nt&gt;</span><span style=3D"color:#660">(</span><span style=3D"color:#008">=
new</span><span style=3D"color:#000"> </span><span style=3D"color:#008">int=
</span><span style=3D"color:#660">(</span><span style=3D"color:#066">7</spa=
n><span style=3D"color:#660">)),</span><span style=3D"color:#000"> bar</spa=
n><span style=3D"color:#660">());</span><span style=3D"color:#000"><br></sp=
an></div></code></div><br>=C2=A0This code seems perfectly reasonable at fir=
st glance; new is called and the result is immediately given to shared_ptr&=
#39;s constructor.=C2=A0 But as Scott Meyers shows in &quot;Effective Moder=
n C++&quot;, if the order of evaluation of the subexpressions is<br>1) new =
int(7)<br>2) bar()<br>3) shared_ptr constructor<br><br>and bar() throws an =
exception, this code can leak. =C2=A0 I don&#39;t think it is reasonable to=
 force users to have to defend against cases like this.<br></div></blockquo=
te><div><br></div><div>If you&#39;re using legacy APIs that produce unmanag=
ed resources, it seems perfectly reasonable to expect users to encapsulate =
those calls; that&#39;s just good style.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7bd75cb08eace20527a5951e--

.

On 2015-12-23 20:57, Joe Gottman wrote:
> Consider the code foo(shared_ptr<int>(new int(7)), bar());

Code review: -1, use make_shared.

> This code seems perfectly reasonable at first glance;

Not really, it's well known that using shared_ptr's ctor directly is
dangerous. (Pretty sure this isn't the only reason for that.)

> new is called and
> the result is immediately given to shared_ptr's constructor.  But as Scott
> Meyers shows in "Effective Modern C++", if the order of evaluation of the
> subexpressions is
> 1) new int(7)
> 2) bar()
> 3) shared_ptr constructor
>
> and bar() throws an exception, this code can leak.

....which is why make_shared exists. The above would not pass reasonable
code review.

> I don't think it is reasonable to force users to have to defend
> against cases like this.

I guess everyone that supported make_shared disagrees?

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 12/24/2015 11:35 AM, Matthew Woehlke wrote:
> On 2015-12-23 20:57, Joe Gottman wrote:
>> new is called and
>> the result is immediately given to shared_ptr's constructor.  But as Sco=
tt
>> Meyers shows in "Effective Modern C++", if the order of evaluation of th=
e
>> subexpressions is
>> 1) new int(7)
>> 2) bar()
>> 3) shared_ptr constructor
>>
>> and bar() throws an exception, this code can leak.
>
> ...which is why make_shared exists. The above would not pass reasonable
> code review.

That is not the reason why `make_shared` exists, the motivation is to=20
perform a single allocation where to place both the object and the=20
control block. Otherwise `make_unique` would have been provided in C++11=20
too, but wasn't.

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

--089e0122eda40c29d10527a83ccd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1

In that specific case, without a standardized order of argument evaluation,
make_shared() would not solve the leak anyway... and neither would a
left-to-right evaluation of arguments :)

Cheers!

2015-12-24 9:44 GMT-05:00 Agust=C3=ADn K-ballo Berg=C3=A9 <kaballo86@hotmai=
l.com>:

> On 12/24/2015 11:35 AM, Matthew Woehlke wrote:
>
>> On 2015-12-23 20:57, Joe Gottman wrote:
>>
>>> new is called and
>>> the result is immediately given to shared_ptr's constructor.  But as
>>> Scott
>>> Meyers shows in "Effective Modern C++", if the order of evaluation of t=
he
>>> subexpressions is
>>> 1) new int(7)
>>> 2) bar()
>>> 3) shared_ptr constructor
>>>
>>> and bar() throws an exception, this code can leak.
>>>
>>
>> ...which is why make_shared exists. The above would not pass reasonable
>> code review.
>>
>
> That is not the reason why `make_shared` exists, the motivation is to
> perform a single allocation where to place both the object and the contro=
l
> block. Otherwise `make_unique` would have been provided in C++11 too, but
> wasn't.
>
> Regards,
> --
> Agust=C3=ADn K-ballo Berg=C3=A9.-
> http://talesofcpp.fusionfenix.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.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">+1<br><br>In that specific case, without a standardized or=
der of argument evaluation, make_shared() would not solve the leak anyway..=
.. and neither would a left-to-right evaluation of arguments :)<br><br>Cheer=
s!<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-=
12-24 9:44 GMT-05:00 Agust=C3=ADn K-ballo Berg=C3=A9 <span dir=3D"ltr">&lt;=
<a href=3D"mailto:kaballo86@hotmail.com" target=3D"_blank">kaballo86@hotmai=
l.com</a>&gt;</span>:<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=
 12/24/2015 11:35 AM, Matthew Woehlke wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
On 2015-12-23 20:57, Joe Gottman wrote:<br>
</span><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
new is called and<br>
the result is immediately given to shared_ptr&#39;s constructor.=C2=A0 But =
as Scott<br>
Meyers shows in &quot;Effective Modern C++&quot;, if the order of evaluatio=
n of the<br>
subexpressions is<br>
1) new int(7)<br>
2) bar()<br>
3) shared_ptr constructor<br>
<br>
and bar() throws an exception, this code can leak.<br>
</blockquote>
<br>
....which is why make_shared exists. The above would not pass reasonable<br>
code review.<br>
</span></blockquote>
<br>
That is not the reason why `make_shared` exists, the motivation is to perfo=
rm a single allocation where to place both the object and the control block=
.. Otherwise `make_unique` would have been provided in C++11 too, but wasn&#=
39;t.<br>
<br>
Regards,<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- <br>
Agust=C3=ADn K-ballo Berg=C3=A9.-<br>
<a href=3D"http://talesofcpp.fusionfenix.com" rel=3D"noreferrer" target=3D"=
_blank">http://talesofcpp.fusionfenix.com</a></font></span><div class=3D"HO=
EnZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e0122eda40c29d10527a83ccd--

.

--047d7bea43fc86db300527a8966e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23 Dec 2015 06:47, "David Krauss" <potswa@gmail.com> wrote:
> The proposal has been met little controversy in over a year of discussion
at the meetings. Anyone facing an actual impact should measure it and write
a paper. Mere speculation isn=E2=80=99t very helpful. This thread seems lik=
e a
waste of breath as long as no data is presented, but fortunately, it
doesn=E2=80=99t seem to reflect what I saw at ISO.
>
> Still, it would be nice to see someone collect the experimental data.

I would very much welcome the opportunity to measure the performance
impact. Do you know whether any of the compiler vendors have tried
implementing the proposal and if so whether there is a branch or patch set
available?

I am sure that if there were a sample compiler implementation then parties
interested in performance would likewise be happy to measure the impact -
say SG14, for starters.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<p dir=3D"ltr"><br>
On 23 Dec 2015 06:47, &quot;David Krauss&quot; &lt;<a href=3D"mailto:potswa=
@gmail.com">potswa@gmail.com</a>&gt; wrote:<br>
&gt; The proposal has been met little controversy in over a year of discuss=
ion at the meetings. Anyone facing an actual impact should measure it and w=
rite a paper. Mere speculation isn=E2=80=99t very helpful. This thread seem=
s like a waste of breath as long as no data is presented, but fortunately, =
it doesn=E2=80=99t seem to reflect what I saw at ISO.<br>
&gt;<br>
&gt; Still, it would be nice to see someone collect the experimental data.<=
/p>
<p dir=3D"ltr">I would very much welcome the opportunity to measure the per=
formance impact. Do you know whether any of the compiler vendors have tried=
 implementing the proposal and if so whether there is a branch or patch set=
 available?</p>
<p dir=3D"ltr">I am sure that if there were a sample compiler implementatio=
n then parties interested in performance would likewise be happy to measure=
 the impact - say SG14, for starters. </p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7bea43fc86db300527a8966e--

.

(Original example:)

  foo(shared_ptr<int>(new int(7)), bar());

On 2015-12-24 12:33, Patrice Roy wrote:
> In that specific case, without a standardized order of argument evaluation,
> make_shared() would not solve the leak anyway... and neither would a
> left-to-right evaluation of arguments :)

Eh?

  foo(make_shared<int>(7), bar());

The 'new' is hidden inside make_shared (as it should be; the appearance
of 'new' was the first sign that something is wrong), which returns a
shared_ptr<int>. In order for memory to be leaked, bar() would have to
be called after make_shared allocates memory but *before it returns*.
Last I checked, there is nothing in C++ that would allow an optimizer to
emit such code.

Either make_shared has not been executed when bar() throws, so nothing
has been allocated yet, or make_shared has completed executing and there
is a fully constructed shared_ptr which gets destroyed when bar() throws
and frees the memory that was allocated. No standardized order of
evaluation is required.

Also, standardizing on right-to-left makes this code less efficient than
if it was executed right to left, at least in the case that bar() may
throw. (Granted, that's an accident of the argument order, but...)

In general, given an expression like:

  foo(expr1, expr2);

....if the compiler knows that one of expr1 / expr2 is non-trivially more
likely to fail (i.e. throw), it may be more efficient to evaluate that
expression first.

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

If expressing non-deterministic computation sequences is important then the
programming language should provide a means for doing so.  But that should
never be the default, because the computation environment does not know
whether the non-determinism was intended by the programmer or whether it is
there by accident because the programmer believed incorrectly that only a
single meaning was possible.

On Thu, Dec 24, 2015 at 2:07 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:

>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8B=E5=8D=8811:53:02=EF=BC=8CDavid Krauss=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>>
>> On 2015=E2=80=9312=E2=80=9323, at 10:20 PM, FrankHB1989 <frank...@gmail.=
com> wrote:
>>
>> For a high level language, there is one thing come before the
>> optimization: expressiveness, which determines the possible interpretati=
on
>> of the code. Opportunity of optimization is granted by a few rules (the
>> "as-if" rule and several other semantics exceptions like rules for copy
>> elision) based on the expressiveness. It will be lost if the new rules a=
re
>> strictly restrictive than before. (Any doubt?)
>>
>> Whether it is significant enough or not, is another story. The data woul=
d
>> be good to illustrate *this *significance, but far from the complete for
>> decision of the evolution, since the change would have *limited users'
>> valid choice* and *no replacement is provided*.
>>
>>
>> What do rules of uncertainty, such as copy elision and unordered
>> operations, usefully express besides optimization opportunities?
>>
> These rules are not all of uncertainty. It is *certainly **unspecified*
> (if not undefined). It is obvious that users should not depend on the
> particular unspecified behavior in a portable C++ program. Optimization i=
s
> nothing to do this principle.
>
> Note that the "unsequenced" for evaluation itself is *not *about
> uncertainty, but *indeterminancy*, which should be one of the key
> characteristics of concurrent computation. (The actual wording is also
> related to this property.) There even exist system for intended
> *nondeterminism*.
>
>
>> If the optimization is of insignificant value, that would seem to imply
>> that the rule is ripe for elimination.
>>
>> Not only significance. To change previously well-defined and clear rules=
,
> you should have some valid reasons. You change them only when the reasons
> are significant enough, or there would be cost in vain.
>
> The optimization is valuable. Do the changes gives us more?
>
>
>> The analysis is similar for guaranteed copy elision, which has also been
>> added to C++17: the language (i.e., its designers) never intended to
>> express uncertainty, but only to run fast.
>>
> To allow programs running fast is a major goal of C++, but not the *only =
*one,
> and not always the most important one.
>
>
>> Corner cases even exist where P0135R0 actually eliminates copy elision,
>> but they are considered insignificant.
>>
>> This just show that there have been something come before the
> optimization purpose, *by design*.
>
> And even if copy elision is eliminated in some cases, they do not harm th=
e
> result or goal of the optimization itself. No copy/move is generally more
> efficient than a move. Note that there is rules depending on copy elision
> (12.8/32 IIRC) which can "transform" a previously (in C++98/03 era) copy =
to
> a move, but it is not able to transform a move to no-op. Note also the
> rules are not making sure the result is more optimized: a move would be
> equal to (or worse than, for an insane move constructor implementation) a
> copy for several types. But they have already been semantically different=
..
> The change for cases when optimization will not effect should also not be
> accepted unconditionally.
>
> The as-if rule isn=E2=80=99t a distinct rule at all, it=E2=80=99s just a =
clarification of
>> the fact that the standard only describes a distinct set of behaviors wh=
en
>> a computer runs a program that was written in C++.
>>
>> No, the as-if rule and the remained rules are different in view of users=
,
> because the former guarantees *no observable behavior would be changed*
> by some usual transformation (by optimization) according to the rule. I
> treat the remained as "exceptions", because they are special concerned wi=
th
> very limited set of features and they are surprising to users. They are
> also special because rare occur in other languages. In fact, ISO C has
> almost the same rule about observable behavior equivalence (though withou=
t
> "as-if" wording), but it has nothing about copy elision or merging of
> allocation function calls (which can eliminate the potential side effects
> in debug code), etc. (Think twice: why 'g++ -O0' does not turn off copy
> elision?)
>
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">If expressing non-deterministic computation sequences is i=
mportant then the programming language should provide a means for doing so.=
=C2=A0 But that should never be the default, because the computation enviro=
nment does not know whether the non-determinism was intended by the program=
mer or whether it is there by accident because the programmer believed inco=
rrectly that only a single meaning was possible.</div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Thu, Dec 24, 2015 at 2:07 AM, Frank=
HB1989 <span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com" targe=
t=3D"_blank">frankhb1989@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8823=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=8811:53:02=EF=BC=8CDavid Krauss=
=E5=86=99=E9=81=93=EF=BC=9A<span class=3D""><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"c=
ite"><div>On 2015=E2=80=9312=E2=80=9323, at 10:20 PM, FrankHB1989 &lt;<a re=
l=3D"nofollow">frank...@gmail.com</a>&gt; wrote:</div><br><div>For a high l=
evel language, there is one thing come before the optimization: expressiven=
ess, which determines the possible interpretation of the code. Opportunity =
of optimization is granted by a few rules (the &quot;as-if&quot; rule and s=
everal other semantics exceptions like rules for copy elision) based on the=
 expressiveness. It will be lost if the new rules are strictly restrictive =
than before. (Any doubt?)<br><div><br>Whether it is significant enough or n=
ot, is another story. The data would be good to illustrate <b>this </b>sign=
ificance, but far from the complete for decision of the evolution, since th=
e change would have <b>limited users&#39; valid choice</b> and <b>no replac=
ement is provided</b>.<br></div></div></blockquote><div><br></div><div>What=
 do rules of uncertainty, such as copy elision and unordered operations, us=
efully express besides optimization opportunities?</div></div></div></block=
quote></span><div>These rules are not all of uncertainty. It is <i>certainl=
y </i><b>unspecified</b>
 (if not undefined). It is obvious that users should not depend on the=20
particular unspecified behavior in a portable C++ program. Optimization=20
is nothing to do this principle.<br><br>Note that the &quot;unsequenced&quo=
t; for evaluation itself is <i>not </i>about uncertainty, but <b>indetermin=
ancy</b>, which should be one of the key characteristics of concurrent comp=
utation. (The actual wording is also related to this property.) There even =
exist system for intended <b>nondeterminism</b>.<br>=C2=A0</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 style=3D"word-wrap:break=
-word"><div><div>If the optimization is of insignificant value, that would =
seem to imply that the rule is ripe for elimination.</div><div><br></div></=
div></div></blockquote></span><div>Not only significance. To change previou=
sly well-defined and clear rules, you should have some valid reasons. You c=
hange them only when the reasons are significant enough, or there would be =
cost in vain.<br><br>The optimization is valuable. Do the changes gives us =
more?<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-lef=
t:1ex"><div style=3D"word-wrap:break-word"><div><div></div><div>The analysi=
s is similar for guaranteed copy elision, which has also been added to C++1=
7: the language (i.e., its designers) never intended to express uncertainty=
, but only to run fast.</div></div></div></blockquote></span><div>To allow =
programs running fast is a major goal of C++, but not the <b>only </b>one, =
and not always the most important one.<br>=C2=A0</div><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"><div style=3D"word-wrap:break-word"><di=
v><div>Corner cases even exist where P0135R0 actually eliminates copy elisi=
on, but they are considered insignificant.</div></div><div><br></div></div>=
</blockquote></span><div>This just show that there have been something come=
 before the optimization purpose, <i>by design</i>.<br><br>And even if copy=
 elision is eliminated in some cases, they do not harm the result or goal o=
f the optimization itself. No copy/move is generally more efficient than a =
move. Note that there is rules depending on copy elision (12.8/32 IIRC) whi=
ch can &quot;transform&quot; a previously (in C++98/03 era) copy to a move,=
 but it is not able to transform a move to no-op. Note also the rules are n=
ot making sure the result is more optimized: a move would be equal to (or w=
orse than, for an insane move constructor implementation) a copy for severa=
l types. But they have already been semantically different. The change for =
cases when optimization will not effect should also not be accepted uncondi=
tionally.<br><br></div><span class=3D""><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div style=3D"word-wrap:break-word"><div></div><div>The as-if rule isn=
=E2=80=99t a distinct rule at all, it=E2=80=99s just a clarification of the=
 fact that the standard only describes a distinct set of behaviors when a c=
omputer runs a program that was written in C++.</div><div><br></div></div><=
/blockquote></span><div>No, the as-if rule and the remained rules are diffe=
rent in view of users, because the former guarantees <b>no observable behav=
ior would be changed</b> by some usual transformation (by optimization) acc=
ording to the rule. I treat the remained as &quot;exceptions&quot;, because=
 they are special concerned with very limited set of features and they are =
surprising to users. They are also special because rare occur in other lang=
uages. In fact, ISO C has almost the same rule about observable behavior eq=
uivalence (though without &quot;as-if&quot; wording), but it has nothing ab=
out copy elision or merging of allocation function calls (which can elimina=
te the potential side effects in debug code), etc. (Think twice: why &#39;g=
++ -O0&#39; does not turn off copy elision?)<br><br><br>=C2=A0<br></div><di=
v class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1143f36cb7b8540527a90fde--

.

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

But what do you say when asked *why* you must call make_shared<int> rather
than shared_ptr<int>(new int(7))?  Why is the appearance of new a sign that
something is wrong?  This is all wrong.  Experts have so internalized the
workarounds for bad language design that they now regard the lack of those
workarounds as the problem rather than placing the blame where it belongs
and then *fixing* it.

On Thu, Dec 24, 2015 at 1:12 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> (Original example:)
>
>   foo(shared_ptr<int>(new int(7)), bar());
>
> On 2015-12-24 12:33, Patrice Roy wrote:
> > In that specific case, without a standardized order of argument
> evaluation,
> > make_shared() would not solve the leak anyway... and neither would a
> > left-to-right evaluation of arguments :)
>
> Eh?
>
>   foo(make_shared<int>(7), bar());
>
> The 'new' is hidden inside make_shared (as it should be; the appearance
> of 'new' was the first sign that something is wrong), which returns a
> shared_ptr<int>. In order for memory to be leaked, bar() would have to
> be called after make_shared allocates memory but *before it returns*.
> Last I checked, there is nothing in C++ that would allow an optimizer to
> emit such code.
>
> Either make_shared has not been executed when bar() throws, so nothing
> has been allocated yet, or make_shared has completed executing and there
> is a fully constructed shared_ptr which gets destroyed when bar() throws
> and frees the memory that was allocated. No standardized order of
> evaluation is required.
>
> Also, standardizing on right-to-left makes this code less efficient than
> if it was executed right to left, at least in the case that bar() may
> throw. (Granted, that's an accident of the argument order, but...)
>
> In general, given an expression like:
>
>   foo(expr1, expr2);
>
> ...if the compiler knows that one of expr1 / expr2 is non-trivially more
> likely to fail (i.e. throw), it may be more efficient to evaluate that
> expression first.
>
> --
> 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.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">But what do you say when asked <i>why</i> you must call <f=
ont face=3D"monospace, monospace">make_shared&lt;int&gt;</font> rather than=
 <font face=3D"monospace, monospace">shared_ptr&lt;int&gt;(new int(7))</fon=
t>?=C2=A0 Why is the appearance of <font face=3D"monospace, monospace">new<=
/font> a sign that something is wrong?=C2=A0 This is all wrong.=C2=A0 Exper=
ts have so internalized the workarounds for bad language design that they n=
ow regard the lack of those workarounds as the problem rather than placing =
the blame where it belongs and then <i>fixing</i> it.</div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Thu, Dec 24, 2015 at 1:12 PM, =
Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmai=
l.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">(Original example:)<br>
<span class=3D""><br>
=C2=A0 foo(shared_ptr&lt;int&gt;(new int(7)), bar());<br>
<br>
</span><span class=3D"">On 2015-12-24 12:33, Patrice Roy wrote:<br>
&gt; In that specific case, without a standardized order of argument evalua=
tion,<br>
&gt; make_shared() would not solve the leak anyway... and neither would a<b=
r>
&gt; left-to-right evaluation of arguments :)<br>
<br>
</span>Eh?<br>
<br>
=C2=A0 foo(make_shared&lt;int&gt;(7), bar());<br>
<br>
The &#39;new&#39; is hidden inside make_shared (as it should be; the appear=
ance<br>
of &#39;new&#39; was the first sign that something is wrong), which returns=
 a<br>
shared_ptr&lt;int&gt;. In order for memory to be leaked, bar() would have t=
o<br>
be called after make_shared allocates memory but *before it returns*.<br>
Last I checked, there is nothing in C++ that would allow an optimizer to<br=
>
emit such code.<br>
<br>
Either make_shared has not been executed when bar() throws, so nothing<br>
has been allocated yet, or make_shared has completed executing and there<br=
>
is a fully constructed shared_ptr which gets destroyed when bar() throws<br=
>
and frees the memory that was allocated. No standardized order of<br>
evaluation is required.<br>
<br>
Also, standardizing on right-to-left makes this code less efficient than<br=
>
if it was executed right to left, at least in the case that bar() may<br>
throw. (Granted, that&#39;s an accident of the argument order, but...)<br>
<br>
In general, given an expression like:<br>
<br>
=C2=A0 foo(expr1, expr2);<br>
<br>
....if the compiler knows that one of expr1 / expr2 is non-trivially more<br=
>
likely to fail (i.e. throw), it may be more efficient to evaluate that<br>
expression first.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a114405c666c3dc0527a939ed--

.

(BTW:)

Because it messes up the order in which people normally read text.
> Why not?
>> Please don't top post.

....and messes up quoting for people that do it right. (And no, I'm not
going to top post. First, because it's bad. Second, because it's
impossible to reply to individual points.)

On 2015-12-24 13:43, Hyman Rosen wrote:
> But what do you say when asked *why* you must call make_shared<int> rather
> than shared_ptr<int>(new int(7))?>

That it's more descriptive (and less typing)? ;-)

> Why is the appearance of new a sign that something is wrong?

Because modern C++ is moving resolutely away from the use of bare 'new'
and 'delete' in user code. Because it's more consistent to simply avoid
them entirely and improve safety by doing so rather than worry about
rules when it is okay to use them and when it isn't. But...

> This is all wrong.  Experts have so internalized the
> workarounds for bad language design that they now regard the lack of those
> workarounds as the problem rather than placing the blame where it belongs
> and then *fixing* it.

....I guess your argument is that none of these problems would exist if
evaluation order were deterministic?

BTW (having not read the proposal), I've heard "left to right" muttered
a lot. Does the proposed "guaranteed ordering" *also* include "depth
first"? Because if it doesn't, it's inadequate. (Also, to the teaching
point, it isn't "just" left to right order, it's depth-first with
left-to-right merging of fully evaluated siblings. Don't forget that
when raving about how much easier it will be to teach.)

(Have you read http://herbsutter.com/gotw/_102/?)

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Thu, Dec 24, 2015 at 2:02 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
>
> BTW (having not read the proposal), I've heard "left to right" muttered
> a lot. Does the proposed "guaranteed ordering" *also* include "depth
> first"? Because if it doesn't, it's inadequate. (Also, to the teaching
> point, it isn't "just" left to right order, it's depth-first with
> left-to-right merging of fully evaluated siblings. Don't forget that
> when raving about how much easier it will be to teach.)
>

I use L2R as shorthand for
    When evaluating expressions:
    (0) def: an expression is fully evaluated when it is evaluated and its
side effects are complete
    (1) for unary operators, the operand is fully evaluated, then the unary
operation is performed
    (2) for binary (non-short-circuiting) operators, the left operand is
fully evaluated, then the right operand is fully evaluated, then the binary
operation is performed.
    (3) for function-call, the function expression is fully evaluated, then
each function parameter is initialized left-to-right from its
fully-evaluated argument expression, then the function is called.
    (4) etc., for any other expression forms not already covered.

Given a() *op1* b() *op2* c(), the functions are to be called in the order
a(), b(), c() regardless of the associativity or precedence of *op1* and
*op2*.  L2R does not change the rules for precedence or associativity, so a
+ b * c still means operator+(a,operator*(b,c)) and a * b + c still means
operator+(operator*(a,b),c).  Is this what you mean by depth-first?

(Have you read http://herbsutter.com/gotw/_102/?)


Yes.  Given provision (3) above, if initializing a function parameter
throws an exception, the previously constructed parameters are destructed
in reverse order.  Thus f(new T, new T) cannot leak if the parameters are
smart pointers.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Dec 24, 2015 at 2:02 PM, Matthew Woehlke <span dir=3D"ltr">&lt;=
<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.flos=
s@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
BTW (having not read the proposal), I&#39;ve heard &quot;left to right&quot=
; muttered<br>
a lot. Does the proposed &quot;guaranteed ordering&quot; *also* include &qu=
ot;depth<br>
first&quot;? Because if it doesn&#39;t, it&#39;s inadequate. (Also, to the =
teaching<br>
point, it isn&#39;t &quot;just&quot; left to right order, it&#39;s depth-fi=
rst with<br>
left-to-right merging of fully evaluated siblings. Don&#39;t forget that<br=
>
when raving about how much easier it will be to teach.)<br></blockquote><di=
v><br>I use L2R as shorthand for<br>=C2=A0 =C2=A0 When evaluating expressio=
ns:</div><div>=C2=A0 =C2=A0 (0) def: an expression is fully evaluated when =
it is evaluated and its side effects are complete<br>=C2=A0 =C2=A0 (1) for =
unary operators, the operand is fully evaluated, then the unary operation i=
s performed<br>=C2=A0 =C2=A0 (2) for binary (non-short-circuiting) operator=
s, the left operand is fully evaluated, then the right operand is fully eva=
luated, then the binary operation is performed.</div><div>=C2=A0 =C2=A0 (3)=
 for function-call, the function expression is fully evaluated, then each f=
unction parameter is initialized left-to-right from its fully-evaluated arg=
ument expression, then the function is called.</div><div>=C2=A0 =C2=A0 (4) =
etc., for any other expression forms not already covered.<br><br>Given <fon=
t face=3D"monospace, monospace">a() <i>op1</i> b() <i>op2</i> c()</font>, t=
he functions are to be called in the order <font face=3D"monospace, monospa=
ce">a()</font>, <font face=3D"monospace, monospace">b()</font>, <font face=
=3D"monospace, monospace">c()</font> regardless of the associativity or pre=
cedence of <font face=3D"monospace, monospace"><i>op1</i></font> and <font =
face=3D"monospace, monospace"><i>op2</i></font>.=C2=A0 L2R does not change =
the rules for precedence or associativity, so <font face=3D"monospace, mono=
space">a + b * c</font> still means <font face=3D"monospace, monospace">ope=
rator+(a,operator*(b,c))</font> and <font face=3D"monospace, monospace">a *=
 b + c</font> still means <font face=3D"monospace, monospace">operator+(ope=
rator*(a,b),c)</font>.=C2=A0 Is this what you mean by depth-first?<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
(Have you read <a href=3D"http://herbsutter.com/gotw/_102/" rel=3D"noreferr=
er" target=3D"_blank">http://herbsutter.com/gotw/_102/</a>?)</blockquote><d=
iv><br>Yes.=C2=A0 Given provision (3) above, if initializing a function par=
ameter throws an exception, the previously constructed parameters are destr=
ucted in reverse order.=C2=A0 Thus <font face=3D"monospace, monospace">f(ne=
w T, new T)</font> cannot leak if the parameters are smart pointers.</div><=
/div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1143f36c1466480527aa088a--

.

--047d7bdc15ea9a5e540527aa20de
Content-Type: text/plain; charset=UTF-8

Oh, if make_shared<int>() (instead of make_shared<bla>(new int(7),
whatever)) is what was meant, it's another story. Cheers!

2015-12-24 13:12 GMT-05:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:

> (Original example:)
>
>   foo(shared_ptr<int>(new int(7)), bar());
>
> On 2015-12-24 12:33, Patrice Roy wrote:
> > In that specific case, without a standardized order of argument
> evaluation,
> > make_shared() would not solve the leak anyway... and neither would a
> > left-to-right evaluation of arguments :)
>
> Eh?
>
>   foo(make_shared<int>(7), bar());
>
> The 'new' is hidden inside make_shared (as it should be; the appearance
> of 'new' was the first sign that something is wrong), which returns a
> shared_ptr<int>. In order for memory to be leaked, bar() would have to
> be called after make_shared allocates memory but *before it returns*.
> Last I checked, there is nothing in C++ that would allow an optimizer to
> emit such code.
>
> Either make_shared has not been executed when bar() throws, so nothing
> has been allocated yet, or make_shared has completed executing and there
> is a fully constructed shared_ptr which gets destroyed when bar() throws
> and frees the memory that was allocated. No standardized order of
> evaluation is required.
>
> Also, standardizing on right-to-left makes this code less efficient than
> if it was executed right to left, at least in the case that bar() may
> throw. (Granted, that's an accident of the argument order, but...)
>
> In general, given an expression like:
>
>   foo(expr1, expr2);
>
> ...if the compiler knows that one of expr1 / expr2 is non-trivially more
> likely to fail (i.e. throw), it may be more efficient to evaluate that
> expression first.
>
> --
> 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.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Oh, if make_shared&lt;int&gt;() (instead of make_shared&lt=
;bla&gt;(new int(7), whatever)) is what was meant, it&#39;s another story. =
Cheers!<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2015-12-24 13:12 GMT-05:00 Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D=
"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.co=
m</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Original example:)<br>
<span class=3D""><br>
=C2=A0 foo(shared_ptr&lt;int&gt;(new int(7)), bar());<br>
<br>
</span><span class=3D"">On 2015-12-24 12:33, Patrice Roy wrote:<br>
&gt; In that specific case, without a standardized order of argument evalua=
tion,<br>
&gt; make_shared() would not solve the leak anyway... and neither would a<b=
r>
&gt; left-to-right evaluation of arguments :)<br>
<br>
</span>Eh?<br>
<br>
=C2=A0 foo(make_shared&lt;int&gt;(7), bar());<br>
<br>
The &#39;new&#39; is hidden inside make_shared (as it should be; the appear=
ance<br>
of &#39;new&#39; was the first sign that something is wrong), which returns=
 a<br>
shared_ptr&lt;int&gt;. In order for memory to be leaked, bar() would have t=
o<br>
be called after make_shared allocates memory but *before it returns*.<br>
Last I checked, there is nothing in C++ that would allow an optimizer to<br=
>
emit such code.<br>
<br>
Either make_shared has not been executed when bar() throws, so nothing<br>
has been allocated yet, or make_shared has completed executing and there<br=
>
is a fully constructed shared_ptr which gets destroyed when bar() throws<br=
>
and frees the memory that was allocated. No standardized order of<br>
evaluation is required.<br>
<br>
Also, standardizing on right-to-left makes this code less efficient than<br=
>
if it was executed right to left, at least in the case that bar() may<br>
throw. (Granted, that&#39;s an accident of the argument order, but...)<br>
<br>
In general, given an expression like:<br>
<br>
=C2=A0 foo(expr1, expr2);<br>
<br>
....if the compiler knows that one of expr1 / expr2 is non-trivially more<br=
>
likely to fail (i.e. throw), it may be more efficient to evaluate that<br>
expression first.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7bdc15ea9a5e540527aa20de--

.

On 2015-12-24 14:41, Hyman Rosen wrote:
> Given a() *op1* b() *op2* c(), the functions are to be called in the order
> a(), b(), c() regardless of the associativity or precedence of *op1* and
> *op2*.  L2R does not change the rules for precedence or associativity, so a
> + b * c still means operator+(a,operator*(b,c)) and a * b + c still means
> operator+(operator*(a,b),c).  Is this what you mean by depth-first?

I meant that for something like:

  a(b(c, d), e(f, g));

....the order of evaluation is: c, d, b, f, g, e, a. The left-most
"thing" is the call to a, which is the LAST thing that actually happened.

(I am suddenly struck by the thought that many of these problems are the
result of infix notation. And that Forth has likely never had this
problem...)

On further thought, I guess you can't really break that, though.
However, given something like:

  a(pow(x, y), sqrt(z), external_function());

....you're going to have an obvious performance penalty from LTR, because
now you almost certainly have to spill the first two arguments to the
stack, whereas with unspecified order, it's much cheaper to call
external_function() first and then use registers to compute the first
two arguments.

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2688_1274579709.1451005634668
Content-Type: multipart/alternative;
 boundary="----=_Part_2689_1469397365.1451005634669"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8B=E5=8D=889:22:52=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 24.12.2015 um 13:27 schrieb FrankHB1989:
>
>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B =
UTC+8=E4=B8=8B=E5=8D=887:52:39=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=
=9A=20
>>
>> Am 24.12.2015 um 12:47 schrieb FrankHB1989:
>>
>> The optimization is of unknown value because we have no data.=20
>>>
>>> No. The change *can* make reordering impossible, thus *may *harm=20
>> optimization. It can be proven with or without data.
>> =20
>>
>> Well then provide a proof and silence this debate once and for all.
>>
>
> Proof to what? The former half is implied by "left-to-right" literally.
>
> The second half... So as I have written: "any doubt"? Do you mean you=20
> believe that not allowing reordering of evaluation will *always *have no=
=20
> effect on optimization?
>
> It doesn't matter what I believe.
>
What are you believing here? The reasoning of proposals, or the methodology=
=20
on proving?
=20

> You said it "can be proven with or without data". Well then do so. Provid=
e=20
> a proof, hand it in to the committee, and then we finally have a basis fo=
r=20
> discussion.
>
 I don't agree that it is needed to hand a proof to "1 > 0" to committee.=
=20
(How is that "basis"? Peano's axioms? ZFC?) This is a waste of time.
As I thought this should not be a problem to committee, since there are=20
more sophisticated cases roughly being a superset of the problems here=20
which have been considered. (Again: why 'kill_dependency'?)

Up until now all we have is anecdotes and speculation. If you say your=20
> position can be proven, prove it.
>
However, as required, I will give you a brief proof here.
First, I have no data about it. The result will not change until there is=
=20
opposite data strongly enough as evidence. So I will not consider the data=
=20
below, until someone provide it.
Second, there exists optimization based on the assumption of that code can=
=20
be reordered. For a typical implementation, the evaluation are to be=20
translated to the generated code, so it will have effect on it.
QED.
For the existence of the optimization based on evaluation reordering cared=
=20
by users, see also=20
http://stackoverflow.com/questions/17328931/at-what-point-is-code-reorderin=
g-in-c-optimization-stopped.
=20

> Just postulating something can be proven is meaningless without=20
> demonstrating the actual proof.
>
>
> I am sure this will not silence this debate because this is not the point=
..
>
> Then what is the point? If you're not trying to prevent the proposal from=
=20
> happening, why waste your time arguing against it? If you know how to pro=
ve=20
> the paper to be wrong or a bad idea I am certain the authors and committe=
e=20
> members alike are very interested to hear it.
>
> Read the posts carefully, please.

The point is against the proposal, but not as you said. I do not see others=
=20
denying that the optimization can be harmed as a consequence of the change.=
=20
Even the authors of the paper did not. (At least P0145R0 does not discuss=
=20
the problem explicitly.) The debate is most of the purpose, the=20
significance of effect on optimization, and/or something else (somewhat off=
=20
topic).


=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8B=E5=8D=889:22:52=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 24.12.2015 um 13:27 schrieb FrankHB1989:<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8B=E5=8D=887:52:39=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.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000"> Am 24.12.2015 um 12:47
            schrieb FrankHB1989:<br>
            <blockquote type=3D"cite">
              <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div style=3D"word-wrap:break-word">
                  <div>The optimization is of unknown value because we
                    have no data.
                    <div><br>
                    </div>
                  </div>
                </div>
              </blockquote>
              <div>No. The change <i>can</i> make reordering
                impossible, thus <i>may </i>harm optimization. It can
                be proven with or without data.<br>
                =C2=A0<br>
              </div>
              <br>
            </blockquote>
            Well then provide a proof and silence this debate once and
            for all.<br>
          </div>
        </blockquote>
        <div><br>
          Proof to what? The former half is implied by &quot;left-to-right&=
quot;
          literally.<br>
          <br>
          The second half... So as I have written: &quot;any doubt&quot;? D=
o you
          mean you believe that not allowing reordering of evaluation
          will <i>always </i>have no effect on optimization?<br>
        </div>
      </div>
    </blockquote>
    It doesn&#39;t matter what I believe.</div></blockquote><div>What are y=
ou believing here? The reasoning of proposals, or the methodology on provin=
g?<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 bgcolor=
=3D"#FFFFFF" text=3D"#000000">You said it &quot;can be proven with or
    without data&quot;. Well then do so. Provide a proof, hand it in to the
    committee, and then we finally have a basis for discussion.</div></bloc=
kquote><div>=C2=A0I don&#39;t agree that it is needed to hand a proof to &q=
uot;1 &gt; 0&quot; to committee. (How is that &quot;basis&quot;? Peano&#39;=
s axioms? ZFC?) This is a waste of time.<br>As I thought this should not be=
 a problem to committee, since there are more sophisticated cases roughly b=
eing a superset of the problems here which have been considered. (Again: wh=
y &#39;kill_dependency&#39;?)<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 bgcolor=3D"#FFFFFF" text=3D"#000000">Up until
    now all we have is anecdotes and speculation. If you say your
    position can be proven, prove it.</div></blockquote><div>However, as re=
quired, I will give you a brief proof here.<br>First, I have no data about =
it. The result will not change until there is opposite data strongly enough=
 as evidence. So I will not consider the data below, until someone provide =
it.<br>Second, there exists optimization based on the assumption of that co=
de can be reordered. For a typical implementation, the evaluation are to be=
 translated to the generated code, so it will have effect on it.<br>QED.<br=
>For the existence of the optimization based on evaluation reordering cared=
 by users, see also http://stackoverflow.com/questions/17328931/at-what-poi=
nt-is-code-reordering-in-c-optimization-stopped.<br>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000"=
>Just postulating something can be
    proven is meaningless without demonstrating the actual proof.<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          I am sure this will not silence this debate because this is
          not the point.<br>
        </div>
      </div>
    </blockquote>
    Then what is the point? If you&#39;re not trying to prevent the proposa=
l
    from happening, why waste your time arguing against it? If you know
    how to prove the paper to be wrong or a bad idea I am certain the
    authors and committee members alike are very interested to hear it.<br>
    <br></div></blockquote><div>Read the posts carefully, please.<br><br>Th=
e point is against the proposal, but not as you said. I do not see others d=
enying that the optimization can be harmed as a consequence of the change. =
Even the authors of the paper did not. (At least P0145R0 does not discuss t=
he problem explicitly.) The debate is most of the purpose, the significance=
 of effect on optimization, and/or something else (somewhat off topic).<br>=
<br><br>=C2=A0</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_2689_1469397365.1451005634669--
------=_Part_2688_1274579709.1451005634668--

.

------=_Part_99_781238193.1451005914553
Content-Type: multipart/alternative;
 boundary="----=_Part_100_535653229.1451005914553"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8B=E5=8D=889:21:54=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Wednesday 23 December 2015 17:57:28 jgot...@gmail.com <javascript:>=20
> wrote:=20
> >  This code seems perfectly reasonable at first glance; new is called an=
d=20
> > the result is immediately given to shared_ptr's constructor.  But as=20
> Scott=20
> > Meyers shows in "Effective Modern C++", if the order of evaluation of=
=20
> the=20
> > subexpressions is=20
> > 1) new int(7)=20
> > 2) bar()=20
> > 3) shared_ptr constructor=20
> >=20
> > and bar() throws an exception, this code can leak.   I don't think it i=
s=20
> > reasonable to force users to have to defend against cases like this.=20
>
> None of the proposals in this mailing list would defend against that sinc=
e=20
> we're talking about left-to-right evaluation. The order would remain as=
=20
> above,=20
> which means bar() needs to be noexcept.=20
>
> Unless someone is proposing right-to-left evaluation of function=20
> arguments. If=20
> so, I'd recommend relaxing it to implementation-defined, so that the orde=
r=20
> is=20
> given by ABI:=20
>
>   void __pascal fp(int a, int b, int c);=20
>   void __cdecl fc(int a, int b, int c);=20
>
>   fp(f(), g(), h());         // order: f(), g(), h()=20
>   fc(f(), g(), h());        // order: h(), g(), f()=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
> Evaluation order of parameters does nothing about calling conventions.=20
Calling conventions do not care about side effects on arguments passing of=
=20
high level languages.=20
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8B=E5=8D=889:21:54=EF=BC=8CThiago Macieira=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;">On Wednesday 23=
 December 2015 17:57:28 <a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"zklQjXmtDwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">jgot...@gmail.com</a> wrote:
<br>&gt; =C2=A0This code seems perfectly reasonable at first glance; new is=
 called and=20
<br>&gt; the result is immediately given to shared_ptr&#39;s constructor. =
=C2=A0But as Scott=20
<br>&gt; Meyers shows in &quot;Effective Modern C++&quot;, if the order of =
evaluation of the=20
<br>&gt; subexpressions is
<br>&gt; 1) new int(7)
<br>&gt; 2) bar()
<br>&gt; 3) shared_ptr constructor
<br>&gt;=20
<br>&gt; and bar() throws an exception, this code can leak. =C2=A0 I don&#3=
9;t think it is=20
<br>&gt; reasonable to force users to have to defend against cases like thi=
s.
<br>
<br>None of the proposals in this mailing list would defend against that si=
nce=20
<br>we&#39;re talking about left-to-right evaluation. The order would remai=
n as above,=20
<br>which means bar() needs to be noexcept.
<br>
<br>Unless someone is proposing right-to-left evaluation of function argume=
nts. If=20
<br>so, I&#39;d recommend relaxing it to implementation-defined, so that th=
e order is=20
<br>given by ABI:
<br>
<br>=C2=A0 void __pascal fp(int a, int b, int c);
<br>=C2=A0 void __cdecl fc(int a, int b, int c);
<br>
<br>=C2=A0 fp(f(), g(), h()); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0// order: f(), g(), h()
<br>=C2=A0 fc(f(), g(), h());=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0// order: h(), g(), f()
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46snt=
z\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;">maciei=
ra.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1Dowztw=
AHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google=
..com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo=
5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote><div>Evaluation order of parameters does nothing about cal=
ling conventions. Calling conventions do not care about side effects on arg=
uments passing of high level languages. <br></div><div>=C2=A0</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_100_535653229.1451005914553--
------=_Part_99_781238193.1451005914553--

.

------=_Part_87_1354908770.1451006468885
Content-Type: multipart/alternative;
 boundary="----=_Part_88_2128714247.1451006468885"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8B=E5=8D=8810:16:48=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Thu, Dec 24, 2015 at 12:01 AM, Hyman Rosen <hyman...@gmail.com=20
> <javascript:>> wrote:
>
>> A programming language is a means for a programmer to instruct a compute=
r=20
>> to carry out a computation.  If the meaning of a program is sufficiently=
=20
>> underspecified such that the computer can carry out a variety of=20
>> computations with different effects, this leads to serious possibility o=
f=20
>> error in the case where the programmer did not realize that some=20
>> interpretation was possible and the one chosen by the implementation was=
=20
>> the one that the programmer expected, because at some point in the futur=
e,=20
>> the implementation may choose the unwelcome interpretation.
>>
>
> Every C++ program is underspecified by that definition; the only way to=
=20
> fully specify behavior is to write in assembly and run on the bare metal.=
=20
> There is a trade-off between expressiveness, performance, and possibility=
=20
> of error.=20
>
> Even assembly cannot meet the expectation. There may be "unspecified"=20
behavior provided by instruction set architecture for variable purpose=20
(e.g. ease of implementing the underlying micro architectures). BTW, there=
=20
exist high level assembly languages (though not in widespreaded use). The=
=20
"real" (physically specified) only way is, you manufacture everything you=
=20
can imagine as long as it have a scale larger than the Planck length.
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8B=E5=8D=8810:16:48=EF=BC=8CEdward Catmur=E5=86=99=E9=81=
=93=EF=BC=9A<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 class=3D"gmail_quote">On Thu, Dec 24, 2015 at 12:01 AM, Hyman Rose=
n <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"dlp2j3iwDwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">hyman...@gmail.com</a>&gt;</span> wrote:<br><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">A programming language is a means for a programmer to=
 instruct a computer to carry out a computation.=C2=A0 If the meaning of a =
program is sufficiently underspecified such that the computer can carry out=
 a variety of computations with different effects, this leads to serious po=
ssibility of error in the case where the programmer did not realize that so=
me interpretation was possible and the one chosen by the implementation was=
 the one that the programmer expected, because at some point in the future,=
 the implementation may choose the unwelcome interpretation.</div></blockqu=
ote><div><br></div><div>Every C++ program is underspecified by that definit=
ion; the only way to fully specify behavior is to write in assembly and run=
 on the bare metal. There is a trade-off between expressiveness, performanc=
e, and possibility of error.=C2=A0</div><div><br></div></div></div></div></=
blockquote><div>Even assembly cannot meet the expectation. There may be &qu=
ot;unspecified&quot; behavior provided by instruction set architecture for =
variable purpose (e.g. ease of implementing the underlying micro architectu=
res). BTW, there exist high level assembly languages (though not in widespr=
eaded use). The &quot;real&quot; (physically specified) only way is, you ma=
nufacture everything you can imagine as long as it have a scale larger than=
 the Planck length.<br>=C2=A0<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_88_2128714247.1451006468885--
------=_Part_87_1354908770.1451006468885--

.

------=_Part_82_1209292895.1451009326088
Content-Type: multipart/alternative;
 boundary="----=_Part_83_1997204644.1451009326089"

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

Okay, there's enough misinformation in this thread that it's gotten even ME=
=20
to weigh in... :P

On Thursday, December 24, 2015 at 1:03:28 PM UTC-8, Matthew Woehlke wrote:
>
> On 2015-12-24 14:41, Hyman Rosen wrote:=20
> > Given a() *op1* b() *op2* c(), the functions are to be called in the=20
> order=20
> > a(), b(), c() regardless of the associativity or precedence of *op1* an=
d=20
> > *op2*.  L2R does not change the rules for precedence or associativity,=
=20
> so a=20
> > + b * c still means operator+(a,operator*(b,c)) and a * b + c still=20
> means=20
> > operator+(operator*(a,b),c).  Is this what you mean by depth-first?=20
>
> I meant that for something like:=20
>
>   a(b(c, d), e(f, g));=20
>
> ...the order of evaluation is: c, d, b, f, g, e, a. The left-most=20
> "thing" is the call to a, which is the LAST thing that actually happened.=
=20
>

What Hyman (and everyone else in this thread, including yourself, once you=
=20
realize it) means by "left-to-right" is that for a(b(c,d),e(f,g)), the=20
order of evaluation is

.. t1 =3D a;
.. t2 =3D b(c,d);
.. t3 =3D e(f,g);
.. then the execution of the function call t1(t2, t3) itself

Evaluating b(c,d) proceeds in the same way: first evaluate b, then c, then=
=20
d, and finally apply the-result-of-evaluating-b to=20
the-result-of-evaluating-c and the-result-of-evaluating-d.

This matters in cases where the "name" of the function expression itself=20
has side effects or accesses global state; e.g.

    foo()(bar());  // t1 =3D foo; t2 =3D t1(); t3 =3D bar; t4 =3D t3(); t2(=
t4);
    ptr->foo(ptr++);  // t1 =3D ptr; t2 =3D t1->foo; t3 =3D ptr++; t2(t3);

=20

> However, given something like:=20
>

>   a(pow(x, y), sqrt(z), external_function());=20
>
> ...you're going to have an obvious performance penalty from LTR, because=
=20
> now you almost certainly have to spill the first two arguments to the=20
> stack, whereas with unspecified order, it's much cheaper to call=20
> external_function() first and then use registers to compute the first=20
> two arguments.=20
>

In that example, you're assuming that x,y,z are global variables, right?=20
Otherwise external_function() couldn't possibly modify them, so the as-if=
=20
rule would apply.
(We're also assuming that pow and sqrt are the standard library functions,=
=20
so external_function() couldn't execute something like "pow =3D otherpow;".=
)

There's several things going on in that example, and I'm not sure which of=
=20
them you wanted to be the primary focus.
- The computation of pow() and sqrt() can be inlined, because the compiler=
=20
knows exactly what those functions do. All major x86 compilers (with=20
-ffast-math) will inline the "sqrt"; they tend not to inline the "pow"=20
unless they can constant-propagate one of the arguments.
- The "observable side effect" of the above code isn't the order in which=
=20
sqrt() and pow() are called, but rather the time at which "x", "y", and "z"=
=20
are loaded (i.e., before or after calling external_function()).
- There is another "observable side effect" of the above code: namely, the=
=20
value of 'errno'. Compilers already ignore 'errno' with -ffast-math.=20
Without -ffast-math, the convention seems to be "perform the operation in=
=20
registers, then, if an error occurred, put the operands back into the=20
argument registers and make a function call."
- GCC 5.3 evaluates function arguments right-to-left, meaning that it will=
=20
"do the right thing" with your example but "do the wrong thing" (i.e.,=20
spill) with a(external_function(), sqrt(x), pow(y,z)).
- Clang 3.7 evaluates function arguments left-to-right, meaning that it=20
will "do the wrong thing" (i.e., spill) with your example but "do the right=
=20
thing" with a(external_function(), sqrt(x), pow(y,z)).

So, basically,
- if you think you're getting optimizations like that today, under today's=
=20
rules, you're definitely wrong;
- if you think GCC and Clang will ever agree on the behavior of that code=
=20
(in the absence of pressure from the Standard), you're probably wrong.


Here's an oversimplified version of the example that kicked off this thread=
=20
way back when:

extern int somewhere();
extern int elsewhere(int,int,int);
int x;

int f() {
    x =3D 1;
    return elsewhere(x, somewhere(), x);
}

The optimal code for f() under today's C++ Standard would obviously be=20
equivalent to

int f() {
    x =3D 1;
    elsewhere(1, somewhere(), 1);
}


I've compiled this locally with Xcode/Clang and on godbolt with every x86=
=20
compiler (Clang, ICC, GCC 4.9, GCC 5.3) as well as ARM and PowerPC=20
(although I do not claim fluency in those assembly languages), all at -O3. =
*All=20
of them* generate a load of the memory address "x" after the return from=20
"somewhere()".
Here's the godbolt link: https://goo.gl/WZILSb
This seems like concrete proof that no major compiler (MSVC possibly=20
excepted) currently performs the optimization that would be harmed by=20
standardizing a fixed order of evaluation. All of Clang, GCC, and Intel=20
already conform *in practice* to an order-of-evaluation rule that *does not=
=20
change* in the presence of optimization opportunities. GCC and Clang happen=
=20
to disagree about whether LTR or RTL evaluation is preferable on x86, but=
=20
hey, that's why we make standards: to *advance* the field by resolving=20
*inconvenient* disagreements between competing implementations.

I've shown several examples in this post of how modern compilers *do not=20
optimize* the things that the "anti-LTR camp" seems to be claiming they do.
I'd be very interested in seeing some examples of code where modern=20
compilers *do* optimize by reordering function parameters or other LTR-type=
=20
stuff.

=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr"><div>Okay, there&#39;s enough misinformation in this threa=
d that it&#39;s gotten even ME to weigh in... :P</div><div><br></div>On Thu=
rsday, December 24, 2015 at 1:03:28 PM UTC-8, Matthew Woehlke wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On 2015-12-24 14:41, Hyman Rosen wrot=
e:
<br>&gt; Given a() *op1* b() *op2* c(), the functions are to be called in t=
he order
<br>&gt; a(), b(), c() regardless of the associativity or precedence of *op=
1* and
<br>&gt; *op2*. =C2=A0L2R does not change the rules for precedence or assoc=
iativity, so a
<br>&gt; + b * c still means operator+(a,operator*(b,c)) and a * b + c stil=
l means
<br>&gt; operator+(operator*(a,b),c). =C2=A0Is this what you mean by depth-=
first?
<br>
<br>I meant that for something like:
<br>
<br>=C2=A0 a(b(c, d), e(f, g));
<br>
<br>...the order of evaluation is: c, d, b, f, g, e, a. The left-most
<br>&quot;thing&quot; is the call to a, which is the LAST thing that actual=
ly happened.
<br></blockquote><div><br></div><div>What Hyman (and everyone else in this =
thread, including yourself, once you realize it) means by &quot;left-to-rig=
ht&quot; is that for a(b(c,d),e(f,g)), the order of evaluation is</div><div=
><br></div><div>. t1 =3D a;</div><div>. t2 =3D b(c,d);</div><div>. t3 =3D e=
(f,g);</div><div>. then the execution of the function call t1(t2, t3) itsel=
f</div><div><br></div><div>Evaluating b(c,d) proceeds in the same way: firs=
t evaluate b, then c, then d, and finally apply the-result-of-evaluating-b =
to the-result-of-evaluating-c and the-result-of-evaluating-d.</div><div><br=
></div><div>This matters in cases where the &quot;name&quot; of the functio=
n expression itself has side effects or accesses global state; e.g.</div><d=
iv><br></div><div>=C2=A0 =C2=A0 foo()(bar()); =C2=A0// t1 =3D foo; t2 =3D t=
1(); t3 =3D bar; t4 =3D t3(); t2(t4);<br></div><div>=C2=A0 =C2=A0 ptr-&gt;f=
oo(ptr++); =C2=A0// t1 =3D ptr; t2 =3D t1-&gt;foo; t3 =3D ptr++; t2(t3);</d=
iv><div><br></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;">However, given something like:=C2=A0<br></blockquote><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
<br>=C2=A0 a(pow(x, y), sqrt(z), external_function());
<br>
<br>...you&#39;re going to have an obvious performance penalty from LTR, be=
cause
<br>now you almost certainly have to spill the first two arguments to the
<br>stack, whereas with unspecified order, it&#39;s much cheaper to call
<br>external_function() first and then use registers to compute the first
<br>two arguments.
<br></blockquote><div><br></div><div>In that example, you&#39;re assuming t=
hat x,y,z are global variables, right? Otherwise external_function() couldn=
&#39;t possibly modify them, so the as-if rule would apply.</div><div>(We&#=
39;re also assuming that pow and sqrt are the standard library functions, s=
o external_function() couldn&#39;t execute something like &quot;pow =3D oth=
erpow;&quot;.)</div><div><br></div><div>There&#39;s several things going on=
 in that example, and I&#39;m not sure which of them you wanted to be the p=
rimary focus.</div><div>- The computation of pow() and sqrt() can be inline=
d, because the compiler knows exactly what those functions do. All major x8=
6 compilers (with -ffast-math) will inline the &quot;sqrt&quot;; they tend =
not to inline the &quot;pow&quot; unless they can constant-propagate one of=
 the arguments.</div><div>- The &quot;observable side effect&quot; of the a=
bove code isn&#39;t the order in which sqrt() and pow() are called, but rat=
her the time at which &quot;x&quot;, &quot;y&quot;, and &quot;z&quot; are l=
oaded (i.e., before or after calling external_function()).</div><div>- Ther=
e is another &quot;observable side effect&quot; of the above code: namely, =
the value of &#39;errno&#39;. Compilers already ignore &#39;errno&#39; with=
 -ffast-math. Without -ffast-math, the convention seems to be &quot;perform=
 the operation in registers, then, if an error occurred, put the operands b=
ack into the argument registers and make a function call.&quot;</div><div>-=
 GCC 5.3 evaluates function arguments right-to-left, meaning that it will &=
quot;do the right thing&quot; with your example but &quot;do the wrong thin=
g&quot; (i.e., spill) with a(external_function(), sqrt(x), pow(y,z)).</div>=
<div>- Clang 3.7 evaluates function arguments left-to-right, meaning that i=
t will &quot;do the wrong thing&quot; (i.e., spill) with your example but &=
quot;do the right thing&quot; with a(external_function(), sqrt(x), pow(y,z)=
).</div><div><br></div><div>So, basically,</div><div>- if you think you&#39=
;re getting optimizations like that today, under today&#39;s rules, you&#39=
;re definitely wrong;</div><div>- if you think GCC and Clang will ever agre=
e on the behavior of that code (in the absence of pressure from the Standar=
d), you&#39;re probably wrong.</div><div><br></div><div><br></div><div>Here=
&#39;s an oversimplified version of the example that kicked off this thread=
 way back when:</div><div><br></div><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); wo=
rd-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #008;" class=3D"styled-by-prettify">extern</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> somewhere</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">extern</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> elsewhere</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #008;" 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"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><font co=
lor=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span></font><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 x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> elsewhere</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><font color=3D"#0000=
00"><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span></fon=
t><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> somewhere</span><span s=
tyle=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;" c=
lass=3D"styled-by-prettify"><br></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></div></code></div><div><br></div><div>The optima=
l code for f() under today&#39;s C++ Standard would obviously be equivalent=
 to</div><div><br></div><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: bre=
ak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">()</span><font color=3D"#000000"><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span></font><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 x </span><span s=
tyle=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"styled-by-prettify">1</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 elsewhere</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> somewhere</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(),</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</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><div>=
<br></div><div><br></div><div>I&#39;ve compiled this locally with Xcode/Cla=
ng and on godbolt with every x86 compiler (Clang, ICC, GCC 4.9, GCC 5.3) as=
 well as ARM and PowerPC (although I do not claim fluency in those assembly=
 languages), all at -O3. <b>All of them</b> generate a load of the memory a=
ddress &quot;x&quot; after the return from &quot;somewhere()&quot;.</div><d=
iv>Here&#39;s the godbolt link: <a href=3D"https://goo.gl/WZILSb">https://g=
oo.gl/WZILSb</a><br></div><div>This seems like concrete proof that no major=
 compiler (MSVC possibly excepted) currently performs the optimization that=
 would be harmed by standardizing a fixed order of evaluation. All of Clang=
, GCC, and Intel already conform <i>in practice</i> to an order-of-evaluati=
on rule that <i>does not change</i> in the presence of optimization opportu=
nities. GCC and Clang happen to disagree about whether LTR or RTL evaluatio=
n is preferable on x86, but hey, that&#39;s why we make standards: to <i>ad=
vance</i> the field by resolving <i>inconvenient</i> disagreements between =
competing implementations.</div><div><br></div><div>I&#39;ve shown several =
examples in this post of how modern compilers <i>do not optimize</i> the th=
ings that the &quot;anti-LTR camp&quot; seems to be claiming they do.</div>=
<div>I&#39;d be very interested in seeing some examples of code where moder=
n compilers <i>do</i> optimize by reordering function parameters or other L=
TR-type stuff.</div><div><br></div><div>=E2=80=93Arthur<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_83_1997204644.1451009326089--
------=_Part_82_1209292895.1451009326088--

.

------=_Part_2871_1455977053.1451025747702
Content-Type: multipart/alternative;
 boundary="----=_Part_2872_1643381674.1451025747702"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8A=E5=8D=882:44:11=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> But what do you say when asked *why* you must call make_shared<int>=20
> rather than shared_ptr<int>(new int(7))?  Why is the appearance of new a=
=20
> sign that something is wrong?  This is all wrong.  Experts have so=20
> internalized the workarounds for bad language design that they now regard=
=20
> the lack of those workarounds as the problem rather than placing the blam=
e=20
> where it belongs and then *fixing* it.
>
> Because this is probably not the proper use of the 'new' keyword. There=
=20
are several reasons in detais:

   - Use of 'make_shared' instead of new-expression express the explicit=20
   (higher level) intent. Using new-expression of the constructor argument =
is=20
   only one possible implementation of this intent. Exposure of this=20
   implementation is generally bad.
   - The template 'make_shared' has actually optimized for allocation by=20
   the specification. (This is not the case of 'make_unique' though.)
   - Since new-expression has less integrity property (specifically,=20
   exception safety here) as 'make_shared' and 'make_unique' have (well,=20
   guaranteed by indeterminate-sequenced rules for function calls, I'd admi=
t=20
   it is necessary here), it is more error-prone and dangerous, thus it is=
=20
   better to be replaced.
   - There exist cases which new-expression is fair to use. In these cases=
=20
   there would be different requirements. (For example, to implement=20
   'make_unique'.) They are better to be differentiated by pragmatics to ma=
ke=20
   the code clear.
  =20
These rules are almost always true. So 'new' is evil if there are better=20
replacement in general. There are a few exceptions only serve as compromise=
=20
to the implementations:

   - libstdc++'s 'make_shared' uses RTTI, which would bloat code. This is=
=20
   not desirable for platforms with few memory. However, a custom=20
   implementation of 'make_shared' is still better.
   - For debug purpose, 'make_shared' causes more step to trace. This is=20
   minor one, but may be really annoying. Conventional use of=20
   'shared_ptr<T>(new T(xxx))' is still acceptable, when the user have know=
n=20
   there is *no risk to get wrong* (e.g. being the only argument of a=20
   function call which is a full expression).

These exceptions don't make abuse of new-expression legitimate.





--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8825=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=882:44:11=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">But what do you say when asked <i>why</i> you must call <font=
 face=3D"monospace, monospace">make_shared&lt;int&gt;</font> rather than <f=
ont face=3D"monospace, monospace">shared_ptr&lt;int&gt;(new int(7))</font>?=
=C2=A0 Why is the appearance of <font face=3D"monospace, monospace">new</fo=
nt> a sign that something is wrong?=C2=A0 This is all wrong.=C2=A0 Experts =
have so internalized the workarounds for bad language design that they now =
regard the lack of those workarounds as the problem rather than placing the=
 blame where it belongs and then <i>fixing</i> it.</div><div><br></div></bl=
ockquote><div>Because this is probably not the proper use of the &#39;new&#=
39; keyword. There are several reasons in detais:<br><ul><li>Use of &#39;ma=
ke_shared&#39; instead of new-expression express the explicit (higher level=
) intent. Using new-expression of the constructor argument is only one poss=
ible implementation of this intent. Exposure of this implementation is gene=
rally bad.<br></li><li>The template &#39;make_shared&#39; has actually opti=
mized for allocation by the specification. (This is not the case of &#39;ma=
ke_unique&#39; though.)<br></li><li>Since new-expression has less integrity=
 property (specifically, exception safety here) as &#39;make_shared&#39; an=
d &#39;make_unique&#39; have (well, guaranteed by indeterminate-sequenced r=
ules for function calls, I&#39;d admit it is necessary here), it is more er=
ror-prone and dangerous, thus it is better to be replaced.</li><li>There ex=
ist cases which new-expression is fair to use. In these cases there would b=
e different requirements. (For example, to implement &#39;make_unique&#39;.=
) They are better to be differentiated by pragmatics to make the code clear=
..<br></li></ul><p>These rules are almost always true. So &#39;new&#39; is e=
vil if there are better replacement in general. There are a few exceptions =
only serve as compromise to the implementations:<br></p><ul><li>libstdc++&#=
39;s &#39;make_shared&#39; uses RTTI, which would bloat code. This is not d=
esirable for platforms with few memory. However, a custom implementation of=
 &#39;make_shared&#39; is still better.</li><li>For debug purpose, &#39;mak=
e_shared&#39; causes more step to trace. This is minor one, but may be real=
ly annoying. Conventional use of &#39;shared_ptr&lt;T&gt;(new T(xxx))&#39; =
is still acceptable, when the user have known there is <b>no risk to get wr=
ong</b> (e.g. being the only argument of a function call which is a full ex=
pression).</li></ul><p>These exceptions don&#39;t make abuse of new-express=
ion legitimate.<br></p><p><br></p><p><br></p><p><br></p><p><br></p></div></=
div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_2872_1643381674.1451025747702--
------=_Part_2871_1455977053.1451025747702--

.

On Thursday 24 December 2015 17:11:54 FrankHB1989 wrote:
> Evaluation order of parameters does nothing about calling conventions.
> Calling conventions do not care about side effects on arguments passing of
> high level languages.

I disagree. If the calling convention pushes arguments left-to-right, then the
arguments are evaluated from the left to the right. If the calling convention
pushes right-to-left, like most common C calling conventions that C++
inherits, then they're evaluated from the right to the left.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Thursday 24 December 2015 14:41:37 Hyman Rosen wrote:
> Given a() *op1* b() *op2* c(), the functions are to be called in the order
> a(), b(), c() regardless of the associativity or precedence of *op1* and
> *op2*.  L2R does not change the rules for precedence or associativity, so a
> + b * c still means operator+(a,operator*(b,c)) and a * b + c still means
> operator+(operator*(a,b),c).  Is this what you mean by depth-first?

If L2R does not change the rules for associativity, L2R implies R2L for
certain operations.

 a() = b() += c() |= d();
(however poor-taste that might be)

Since the assignment operators are right-to-left, does this imply that the
first call is to d()?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Fri, Dec 25, 2015 at 4:06 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Thursday 24 December 2015 17:11:54 FrankHB1989 wrote:
> > Evaluation order of parameters does nothing about calling conventions.
> > Calling conventions do not care about side effects on arguments passing
of
> > high level languages.
>
> I disagree. If the calling convention pushes arguments left-to-right,
then the
> arguments are evaluated from the left to the right. If the calling
convention
> pushes right-to-left, like most common C calling conventions that C++
> inherits, then they're evaluated from the right to the left.

Your claim is false in practice, at least for Clang on x86.
Besides, most ABIs don't use the stack at all for function calls that take
fewer than, say, four arguments.

Here's a GCC thread from just a month ago showing that GCC evaluates
arguments RTL and Clang LTR:
https://gcc.gnu.org/ml/gcc/2015-11/msg00179.html

Apparently someone has made a patch to make Clang evaluate arguments
RTL-instead-of-LTR based on the value of an environment variable. If you
have the ability to build Clang locally (I don't), you could compare the
code size of binaries built with this option versus not. I suspect you
won't see any significant difference. (There will be a difference, in the
sense that the binaries will not be bit-for-bit identical. I'm just
predicting that it won't be a difference in *performance*.)
http://stackoverflow.com/a/28585930/1424877


On Fri, Dec 25, 2015 at 4:17 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Thursday 24 December 2015 14:41:37 Hyman Rosen wrote:
>> Given a() *op1* b() *op2* c(), the functions are to be called in the
order
>> a(), b(), c() regardless of the associativity or precedence of *op1* and
>> *op2*.  L2R does not change the rules for precedence or associativity,
so a
>> + b * c still means operator+(a,operator*(b,c)) and a * b + c still mean=
s
>> operator+(operator*(a,b),c).  Is this what you mean by depth-first?
>
> If L2R does not change the rules for associativity, L2R implies R2L for
> certain operations.

(Your claim is false. See below.)

>         a() =3D b() +=3D c() |=3D d();
> (however poor-taste that might be)
>
> Since the assignment operators are right-to-left, does this imply that th=
e
> first call is to d()?

No, of course not. Associativity (of the *operator*) has nothing to do with
order of evaluation (of the *operands*). Under LTR rules (Clang), the above
code is exactly 100% equivalent to
    auto&& t1 =3D a();
    auto&& t6 =3D (b() +=3D c() |=3D d());
    t1 =3D t6;

which is to say
    auto&& t1 =3D a();
    auto&& t2 =3D b();
    auto&& t5 =3D (c() |=3D d());
    auto&& t6 =3D (t2 +=3D t5);
    t1 =3D t6;

which is to say
    auto&& t1 =3D a();
    auto&& t2 =3D b();
    auto&& t3 =3D c();
    auto&& t4 =3D d();
    auto&& t5 =3D (t3 |=3D t4);
    auto&& t6 =3D (t2 +=3D t5);
    t1 =3D t6;

Whereas, under RTL rules (GCC), it's exactly 100% equivalent to
    auto&& t1 =3D d();
    auto&& t2 =3D c();
    auto&& t3 =3D (t2 |=3D t1);
    auto&& t4 =3D b();
    auto&& t5 =3D (t4 +=3D t3);
    auto&& t6 =3D a();
    t6 =3D t5;


Here's a Wandbox link for the code that produces the above traces:
http://melpon.org/wandbox/permlink/Ft1i5UGpDE7JENJU
Clang is consistently "a b c d", and GCC is consistently "d c b a".
(GCC's behavior can be explained by the theory that it is RTL even for
function calls to operator=3D or operator+=3D.)

Interestingly, both GCC and Clang change their behavior if you get rid of
some of the baggage:
http://melpon.org/wandbox/permlink/4lCITXx6gOB4NTqz
When a(), b(), c(), d() return just references to "int" instead of
heavyweight objects,
Clang is consistently "a b c d" for function calls and "d c b a" for
assignments.
(Clang's behavior can be explained by the theory that it is LTR for
function calls, but RTL for primitive operator=3D and primitive operator+=
=3D.)
GCC 4.6 is "a d c b"(!) for function calls and "a b c d" for assignments.
GCC 4.7 and later is "a d c b" for function calls AND for assignments.
(GCC 4.7's behavior can be explained by the theory that it is RTL for
function calls and primitive operator+=3D but LTR for primitive operator=3D=
..
GCC 4.6 was LTR for primitive operator+=3D as well.)

Notice that while current vendors' rules are certainly *complicated and
confusing*, all evidence so far points to the theory that they are
*immutable*. I haven't seen an implementation actually change its
order-of-evaluation rules in order to exploit an optimization opportunity.

=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">On Fri, Dec 25, 2015 at 4:06 AM, Thiago Macieira &lt;<a hr=
ef=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>&gt=
; On Thursday 24 December 2015 17:11:54 FrankHB1989 wrote:<br>&gt; &gt; Eva=
luation order of parameters does nothing about calling conventions.<br>&gt;=
 &gt; Calling conventions do not care about side effects on arguments passi=
ng of<br>&gt; &gt; high level languages.<br>&gt;<br>&gt; I disagree. If the=
 calling convention pushes arguments left-to-right, then the<br>&gt; argume=
nts are evaluated from the left to the right. If the calling convention<br>=
&gt; pushes right-to-left, like most common C calling conventions that C++<=
br>&gt; inherits, then they&#39;re evaluated from the right to the left.<br=
><br>Your claim is false in practice, at least for Clang on x86.<br>Besides=
, most ABIs don&#39;t use the stack at all for function calls that take few=
er than, say, four arguments.<br><br><div>Here&#39;s a GCC thread from just=
 a month ago showing that GCC evaluates arguments RTL and Clang LTR: <a hre=
f=3D"https://gcc.gnu.org/ml/gcc/2015-11/msg00179.html">https://gcc.gnu.org/=
ml/gcc/2015-11/msg00179.html<br></a><br>Apparently someone has made a patch=
 to make Clang evaluate arguments RTL-instead-of-LTR based on the value of =
an environment variable. If you have the ability to build Clang locally (I =
don&#39;t), you could compare the code size of binaries built with this opt=
ion versus not. I suspect you won&#39;t see any significant difference. (Th=
ere will be a difference, in the sense that the binaries will not be bit-fo=
r-bit identical. I&#39;m just predicting that it won&#39;t be a difference =
in <i>performance</i>.)</div><div><a href=3D"http://stackoverflow.com/a/285=
85930/1424877">http://stackoverflow.com/a/28585930/1424877<br></a><br><br>O=
n Fri, Dec 25, 2015 at 4:17 AM, Thiago Macieira &lt;<a href=3D"mailto:thiag=
o@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>&gt; On Thursday 24 D=
ecember 2015 14:41:37 Hyman Rosen wrote:<br>&gt;&gt; Given a() *op1* b() *o=
p2* c(), the functions are to be called in the order<br>&gt;&gt; a(), b(), =
c() regardless of the associativity or precedence of *op1* and<br>&gt;&gt; =
*op2*.=C2=A0 L2R does not change the rules for precedence or associativity,=
 so a<br>&gt;&gt; + b * c still means operator+(a,operator*(b,c)) and a * b=
 + c still means<br>&gt;&gt; operator+(operator*(a,b),c).=C2=A0 Is this wha=
t you mean by depth-first?<br>&gt;<br>&gt; If L2R does not change the rules=
 for associativity, L2R implies R2L for<br>&gt; certain operations.</div><d=
iv><br></div><div>(Your claim is false. See below.)</div><div><br>&gt; =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 a() =3D b() +=3D c() |=3D d();<br>&gt; (however po=
or-taste that might be)<br>&gt;<br>&gt; Since the assignment operators are =
right-to-left, does this imply that the<br>&gt; first call is to d()?<br><b=
r></div><div>No, of course not. Associativity (of the <i>operator</i>) has =
nothing to do with order of evaluation (of the <i>operands</i>). Under LTR =
rules (Clang), the above code is exactly 100% equivalent to</div><div>=C2=
=A0 =C2=A0 auto&amp;&amp; t1 =3D a();</div><div>=C2=A0 =C2=A0 auto&amp;&amp=
; t6 =3D (b() +=3D c() |=3D d());</div><div>=C2=A0 =C2=A0 t1 =3D t6;</div><=
div><br></div><div>which is to say</div><div><div>=C2=A0 =C2=A0 auto&amp;&a=
mp; t1 =3D a();</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t2 =3D b();</div><di=
v>=C2=A0 =C2=A0 auto&amp;&amp; t5 =3D (c() |=3D d());</div><div>=C2=A0 =C2=
=A0 auto&amp;&amp; t6 =3D (t2 +=3D t5);</div><div>=C2=A0 =C2=A0 t1 =3D t6;<=
/div></div><div><br></div><div>which is to say</div><div><div>=C2=A0 =C2=A0=
 auto&amp;&amp; t1 =3D a();</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t2 =3D b=
();</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t3 =3D c();</div><div>=C2=A0 =C2=
=A0 auto&amp;&amp; t4 =3D d();</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t5 =
=3D (t3 |=3D t4);</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t6 =3D (t2 +=3D t5=
);</div><div>=C2=A0 =C2=A0 t1 =3D t6;<br></div></div><div><br></div><div>Wh=
ereas, under RTL rules (GCC), it&#39;s exactly 100% equivalent to</div><div=
><div>=C2=A0 =C2=A0 auto&amp;&amp; t1 =3D d();</div><div>=C2=A0 =C2=A0 auto=
&amp;&amp; t2 =3D c();</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t3 =3D (t2 |=
=3D t1);</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t4 =3D b();</div><div>=C2=
=A0 =C2=A0 auto&amp;&amp; t5 =3D (t4 +=3D t3);<br></div><div>=C2=A0 =C2=A0 =
auto&amp;&amp; t6 =3D a();</div><div>=C2=A0 =C2=A0 t6 =3D t5;<br></div></di=
v><div><br></div><div><br></div><div>Here&#39;s a Wandbox link for the code=
 that produces the above traces:</div><div><a href=3D"http://melpon.org/wan=
dbox/permlink/Ft1i5UGpDE7JENJU">http://melpon.org/wandbox/permlink/Ft1i5UGp=
DE7JENJU<br></a></div><div>Clang is consistently &quot;a b c d&quot;, and G=
CC is consistently &quot;d c b a&quot;.</div><div>(GCC&#39;s behavior can b=
e explained by the theory that it is RTL even for function calls to operato=
r=3D or operator+=3D.)</div><div><br></div><div>Interestingly, both GCC and=
 Clang change their behavior if you get rid of some of the baggage:</div><d=
iv><a href=3D"http://melpon.org/wandbox/permlink/4lCITXx6gOB4NTqz">http://m=
elpon.org/wandbox/permlink/4lCITXx6gOB4NTqz<br></a></div><div>When a(), b()=
, c(), d() return just references to &quot;int&quot; instead of heavyweight=
 objects,</div><div>Clang is consistently &quot;a b c d&quot; for function =
calls and &quot;d c b a&quot; for assignments.</div><div>(Clang&#39;s behav=
ior can be explained by the theory that it is LTR for function calls, but R=
TL for primitive operator=3D and primitive operator+=3D.)</div><div>GCC 4.6=
 is &quot;a d c b&quot;(!) for function calls and &quot;a b c d&quot; for a=
ssignments.</div><div>GCC 4.7 and later is &quot;a d c b&quot; for function=
 calls AND for assignments.</div><div>(GCC 4.7&#39;s behavior can be explai=
ned by the theory that it is RTL for function calls and primitive operator+=
=3D but LTR for primitive operator=3D. GCC 4.6 was LTR for primitive operat=
or+=3D as well.)</div><div><br></div><div>Notice that while current vendors=
&#39; rules are certainly=C2=A0<i>complicated and confusing</i>, all eviden=
ce so far points to the theory that they are <i>immutable</i>. I haven&#39;=
t seen an implementation actually change its order-of-evaluation rules in o=
rder to exploit an optimization opportunity.</div><div><br></div><div>=E2=
=80=93Arthur</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a11443d7eeaa6c60527bd9b13--

.

On Friday 25 December 2015 11:03:21 Arthur O'Dwyer wrote:
> > pushes right-to-left, like most common C calling conventions that C++
> > inherits, then they're evaluated from the right to the left.
>
> Your claim is false in practice, at least for Clang on x86.

Or true in practice, at least for GCC on x86.

> Besides, most ABIs don't use the stack at all for function calls that take
> fewer than, say, four arguments.

Which means they do use the stack for more than 6 (7 for SPARC and 8 for
IA-64) or in some ABIs for any variadic functions which means there's a
specific order.

> > If L2R does not change the rules for associativity, L2R implies R2L for
> > certain operations.
>
> (Your claim is false. See below.)

That's not what I meant. I asked whether Hyman's proposal that the
associativity rules remaining unchanged should mean that the right-to-left
associativity of the assignment operators imply RTL evaluation.

> Notice that while current vendors' rules are certainly *complicated and
> confusing*, all evidence so far points to the theory that they are
> *immutable*. I haven't seen an implementation actually change its
> order-of-evaluation rules in order to exploit an optimization opportunity.

Indeed, at least in the absence of further optimisation hints, like [[pure]],
__attribute__((pure)) and __attribute__((const)).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e0122ebe62097ca0527c15f5f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 25, 2015 at 2:17 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Friday 25 December 2015 11:03:21 Arthur O'Dwyer wrote:
>> > pushes right-to-left, like most common C calling conventions that C++
>> > inherits, then they're evaluated from the right to the left.
>>
>> Your claim is false in practice, at least for Clang on x86.
>
> Or true in practice, at least for GCC on x86.

Sorry, I should have been blunter. Let me put it this way:
There is no implication-relation between "order of arguments on the stack
(if any)" and "order of evaluation of operands' side effects".
The two have the same value on some implementations, and different values
on other implementations.


>> > If L2R does not change the rules for associativity, L2R implies R2L fo=
r
>> > certain operations.
>>
>> (Your claim is false. See below.)
>
> That's not what I meant. I asked whether Hyman's proposal that the
> associativity rules remaining unchanged should mean that the right-to-lef=
t
> associativity of the assignment operators imply RTL evaluation.

Ah. Then the answer to your question is "No."
There is no implication-relation between "associativity of operators" and
"order of evaluation of operands".

However, P0145r0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf> does
explicitly propose that the order of evaluation for assignment operators
(both =3D and +=3D) be RTL;
that is, they want "a() +=3D b()" to evaluate b() before a(). This is not a
logical consequence of the associativity, though; it's just what they
decided to propose.
In my personal opinion RTL-for-assignments is a silly idea; I would prefer
to see a() evaluated before b() no matter whether the symbol between them
is + or +=3D.


>> Notice that while current vendors' rules are certainly *complicated and
>> confusing*, all evidence so far points to the theory that they are
>> *immutable*. I haven't seen an implementation actually change its
>> order-of-evaluation rules in order to exploit an optimization
opportunity.
>
> Indeed, at least in the absence of further optimisation hints, like
[[pure]],
> __attribute__((pure)) and __attribute__((const)).

This is progress! :)
The goalposts have moved now from a broad and easily falsifiable "does LTR
affect the performance of typical code" (no, according to the evidence it
seems that it doesn't) to a much more distant and easier-to-ignore "is it
even *possible*, perhaps through the use of compiler extensions and
attributes such as [[pure]], to *construct* a case where LTR affects
performance?"

However, I'd still be interested to see an actual statistical survey of the
effects of CLANG_REVERSE_ARGS
<http://stackoverflow.com/questions/28570758/can-i-change-the-order-of-argu=
ment-evaluation-in-clang>
on a real codebase. Or, even better, a statistical survey using some
(currently hypothetical) compiler that would change its order of evaluation
based on some heuristic such as "minimize register pressure" or "minimize
memory loads".

=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">On Fri, Dec 25, 2015 at 2:17 PM, Thiago Macieira &lt;<a hr=
ef=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>&gt=
; On Friday 25 December 2015 11:03:21 Arthur O&#39;Dwyer wrote:<br>&gt;&gt;=
 &gt; pushes right-to-left, like most common C calling conventions that C++=
<br>&gt;&gt; &gt; inherits, then they&#39;re evaluated from the right to th=
e left.<br>&gt;&gt;<br>&gt;&gt; Your claim is false in practice, at least f=
or Clang on x86.<br>&gt;<br>&gt; Or true in practice, at least for GCC on x=
86.<br><br>Sorry, I should have been blunter. Let me put it this way:<div>T=
here is no implication-relation between &quot;order of arguments on the sta=
ck (if any)&quot; and &quot;order of evaluation of operands&#39; side effec=
ts&quot;.</div><div>The two have the same value on some implementations, an=
d different values on other implementations.</div><div><br></div><div><br><=
/div><div>&gt;&gt; &gt; If L2R does not change the rules for associativity,=
 L2R implies R2L for<br>&gt;&gt; &gt; certain operations.<br>&gt;&gt;<br>&g=
t;&gt; (Your claim is false. See below.)<br>&gt;<br>&gt; That&#39;s not wha=
t I meant. I asked whether Hyman&#39;s proposal that the<br>&gt; associativ=
ity rules remaining unchanged should mean that the right-to-left<br>&gt; as=
sociativity of the assignment operators imply RTL evaluation.</div><div><br=
></div><div>Ah. Then the answer to your question is &quot;No.&quot;</div><d=
iv>There is no implication-relation between &quot;associativity of operator=
s&quot; and &quot;order of evaluation of operands&quot;.</div><div><br></di=
v><div>However, <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pape=
rs/2015/p0145r0.pdf">P0145r0</a>=C2=A0does explicitly propose that the orde=
r of evaluation for assignment operators (both =3D and +=3D) be RTL;</div><=
div>that is, they want &quot;a() +=3D b()&quot; to evaluate b() before a().=
 This is not a logical consequence of the associativity, though; it&#39;s j=
ust what they decided to propose.</div><div>In my personal opinion RTL-for-=
assignments is a silly idea; I would prefer to see a() evaluated before b()=
 no matter whether the symbol between them is + or +=3D.</div><div><br></di=
v><div><br></div><div>&gt;&gt; Notice that while current vendors&#39; rules=
 are certainly *complicated and<br>&gt;&gt; confusing*, all evidence so far=
 points to the theory that they are<br>&gt;&gt; *immutable*. I haven&#39;t =
seen an implementation actually change its<br>&gt;&gt; order-of-evaluation =
rules in order to exploit an optimization opportunity.<br>&gt;<br>&gt; Inde=
ed, at least in the absence of further optimisation hints, like [[pure]],<b=
r>&gt; __attribute__((pure)) and __attribute__((const)).</div><div><br></di=
v><div>This is progress! :)</div><div>The goalposts have moved now from a b=
road and easily falsifiable &quot;does LTR affect the performance of typica=
l code&quot; (no, according to the evidence it seems that it doesn&#39;t) t=
o a much more distant and easier-to-ignore &quot;is it even <i>possible</i>=
, perhaps through the use of compiler extensions and attributes such as [[p=
ure]], to <i>construct</i> a case where LTR affects performance?&quot;<br><=
/div><div><br></div><div>However, I&#39;d still be interested to see an act=
ual statistical survey of the effects of <a href=3D"http://stackoverflow.co=
m/questions/28570758/can-i-change-the-order-of-argument-evaluation-in-clang=
">CLANG_REVERSE_ARGS</a> on a real codebase. Or, even better, a statistical=
 survey using some (currently hypothetical) compiler that would change its =
order of evaluation based on some heuristic such as &quot;minimize register=
 pressure&quot; or &quot;minimize memory loads&quot;.</div><div><br></div><=
div>=E2=80=93Arthur</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e0122ebe62097ca0527c15f5f--

.

------=_Part_65_528348731.1451098884630
Content-Type: multipart/alternative;
 boundary="----=_Part_66_188020404.1451098884630"

------=_Part_66_188020404.1451098884630
Content-Type: text/plain; charset=UTF-8

On Friday, December 25, 2015 at 6:32:43 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Fri, Dec 25, 2015 at 2:17 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
> > That's not what I meant. I asked whether Hyman's proposal that the
> > associativity rules remaining unchanged should mean that the
> right-to-left
> > associativity of the assignment operators imply RTL evaluation.
>
> Ah. Then the answer to your question is "No."
> There is no implication-relation between "associativity of operators" and
> "order of evaluation of operands".
>
> However, P0145r0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf> does
> explicitly propose that the order of evaluation for assignment operators
> (both = and +=) be RTL;
> that is, they want "a() += b()" to evaluate b() before a(). This is not a
> logical consequence of the associativity, though; it's just what they
> decided to propose.
> In my personal opinion RTL-for-assignments is a silly idea; I would prefer
> to see a() evaluated before b() no matter whether the symbol between them
> is + or +=.
>

I can understand why. It has to do with the order of evaluation of the
operators themselves.

In order to do LTR for assignments for `a() = b() += c() |= d()`, you have
to keep around lots of temporary state. *Live* temporary state. Consider
the two decompositions:

RTL:

    auto&& t1 = d();
    auto&& t2 = c();
    auto&& t3 = (t2 |= t1);
    auto&& t4 = b();
    auto&& t5 = (t4 += t3);
    auto&& t6 = a();


LTR:

    auto&& t1 = a();
    auto&& t2 = b();
    auto&& t3 = c();
    auto&& t4 = d();
    auto&& t5 = (t3 |= t4);
    auto&& t6 = (t2 += t5);

In both cases, the rules of C++ require that destructors for the
temporaries only be called after the expression has finished. However, if
the results of those function calls have trivial destructors, then nothing
needs to be called. An RTL processor, in accord with the "as if" rule, can
reclaim the storage for `t1` and `t2` immediately after the computation of
`t3` (indeed, even having `t3` overwrite one of them). In the best case
scenario, you only ever have 2 temporaries. In the LTR case, the system
must store 4 temporaries.

Now granted, I don't think that's a big deal; and *certainly* not enough of
one to reverse the order of evaluation for. But that's probably the
argument they would use.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Friday, December 25, 2015 at 6:32:43 PM UTC-5, Arthur O&#39;Dwyer wrote:=
<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">On Fri, Dec 2=
5, 2015 at 2:17 PM, Thiago Macieira &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"204YLWMdEAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">thi...@macieira.org</a>&gt; wrote:<br><=
div>&gt; That&#39;s not what I meant. I asked whether Hyman&#39;s proposal =
that the<br>&gt; associativity rules remaining unchanged should mean that t=
he right-to-left<br>&gt; associativity of the assignment operators imply RT=
L evaluation.</div><div><br></div><div>Ah. Then the answer to your question=
 is &quot;No.&quot;</div><div>There is no implication-relation between &quo=
t;associativity of operators&quot; and &quot;order of evaluation of operand=
s&quot;.</div><div><br></div><div>However, <a href=3D"http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%=
3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp014=
5r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEbZmJOL_yEiq8zVZJqtZDlIWhk2w&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75h=
ttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2F=
p0145r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEbZmJOL_yEiq8zVZJqtZDlIWhk2w=
&#39;;return true;">P0145r0</a>=C2=A0does explicitly propose that the order=
 of evaluation for assignment operators (both =3D and +=3D) be RTL;</div><d=
iv>that is, they want &quot;a() +=3D b()&quot; to evaluate b() before a(). =
This is not a logical consequence of the associativity, though; it&#39;s ju=
st what they decided to propose.</div><div>In my personal opinion RTL-for-a=
ssignments is a silly idea; I would prefer to see a() evaluated before b() =
no matter whether the symbol between them is + or +=3D.</div></div></blockq=
uote><div><br>I can understand why. It has to do with the order of evaluati=
on of the operators themselves.<br><br>In order to do LTR for assignments f=
or `a() =3D b() +=3D c() |=3D d()`, you have to keep around lots of tempora=
ry state. <i>Live</i> temporary state. Consider the two decompositions:<br>=
<br>RTL:<br><br>=C2=A0 =C2=A0 auto&amp;&amp; t1 =3D d();<div>=C2=A0 =C2=A0 =
auto&amp;&amp; t2 =3D c();</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t3 =3D (t=
2 |=3D t1);</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t4 =3D b();</div><div>=
=C2=A0 =C2=A0 auto&amp;&amp; t5 =3D (t4 +=3D t3);<br></div><div>=C2=A0 =C2=
=A0 auto&amp;&amp; t6 =3D a();</div><br><br>LTR:<br><br><div><div>=C2=A0 =
=C2=A0 auto&amp;&amp; t1 =3D a();</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t2=
 =3D b();</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t3 =3D c();</div><div>=C2=
=A0 =C2=A0 auto&amp;&amp; t4 =3D d();</div><div>=C2=A0 =C2=A0 auto&amp;&amp=
; t5 =3D (t3 |=3D t4);</div><div>=C2=A0 =C2=A0 auto&amp;&amp; t6 =3D (t2 +=
=3D t5);<br><br>In both cases, the rules of C++ require that destructors fo=
r the temporaries only be called after the expression has finished. However=
, if the results of those function calls have trivial destructors, then not=
hing needs to be called. An RTL processor, in accord with the &quot;as if&q=
uot; rule, can reclaim the storage for `t1` and `t2` immediately after the =
computation of `t3` (indeed, even having `t3` overwrite one of them). In th=
e best case scenario, you only ever have 2 temporaries. In the LTR case, th=
e system must store 4 temporaries.<br><br>Now granted, I don&#39;t think th=
at&#39;s a big deal; and <i>certainly</i> not enough of one to reverse the =
order of evaluation for. But that&#39;s probably the argument they would us=
e.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_66_188020404.1451098884630--
------=_Part_65_528348731.1451098884630--

.

------=_Part_4722_683283485.1451209868628
Content-Type: multipart/alternative;
 boundary="----=_Part_4723_232658153.1451209868628"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8B=E5=8D=888:06:39=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Thursday 24 December 2015 17:11:54 FrankHB1989 wrote:=20
> > Evaluation order of parameters does nothing about calling conventions.=
=20
> > Calling conventions do not care about side effects on arguments passing=
=20
> of=20
> > high level languages.=20
>
> I disagree. If the calling convention pushes arguments left-to-right, the=
n=20
> the=20
> arguments are evaluated from the left to the right. If the calling=20
> convention=20
> pushes right-to-left, like most common C calling conventions that C++=20
> inherits, then they're evaluated from the right to the left.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
> No. C++ have nothing to do with "push" the arguments. This is only=20
concerned with some implementations. However, even for the implementations=
=20
that have the same such specific calling convention, the actual evaluation=
=20
can still be different (e.g. x86 g++ vs clang++). And when the call is=20
inlined, there may be no such "push" at all, but the evaluation order still=
=20
matters.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=94 UTC+8=E4=B8=8B=E5=8D=888:06:39=EF=BC=8CThiago Macieira=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;">On Thursday 24 =
December 2015 17:11:54 FrankHB1989 wrote:
<br>&gt; Evaluation order of parameters does nothing about calling conventi=
ons.=20
<br>&gt; Calling conventions do not care about side effects on arguments pa=
ssing of=20
<br>&gt; high level languages.=20
<br>
<br>I disagree. If the calling convention pushes arguments left-to-right, t=
hen the=20
<br>arguments are evaluated from the left to the right. If the calling conv=
ention=20
<br>pushes right-to-left, like most common C calling conventions that C++=
=20
<br>inherits, then they&#39;re evaluated from the right to the left.
<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&#39;http://www.goo=
gle.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46snt=
z\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;">maciei=
ra.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1Dowztw=
AHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google=
..com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo=
5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote><div>No. C++ have nothing to do with &quot;push&quot; the =
arguments. This is only concerned with some implementations. However, even =
for the implementations that have the same such specific calling convention=
, the actual evaluation can still be different (e.g. x86 g++ vs clang++). A=
nd when the call is inlined, there may be no such &quot;push&quot; at all, =
but the evaluation order still matters. <br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_4723_232658153.1451209868628--
------=_Part_4722_683283485.1451209868628--

.

On Saturday 26 December 2015 00:32:41 Arthur O'Dwyer wrote:
> >> Notice that while current vendors' rules are certainly *complicated and
> >> confusing*, all evidence so far points to the theory that they are
> >> *immutable*. I haven't seen an implementation actually change its
> >> order-of-evaluation rules in order to exploit an optimization
>
> opportunity.
>
> > Indeed, at least in the absence of further optimisation hints, like
>
> [[pure]],
>
> > __attribute__((pure)) and __attribute__((const)).
>
> This is progress! :)
> The goalposts have moved now from a broad and easily falsifiable "does LTR
> affect the performance of typical code" (no, according to the evidence it
> seems that it doesn't) to a much more distant and easier-to-ignore "is it
> even *possible*, perhaps through the use of compiler extensions and
> attributes such as [[pure]], to construct a case where LTR affects
> performance?"

The discussion on optimizability, from an observer's pov, was never about fixed
RTL vs. LTR. Obviously, they have the same performance on average, given a
uniform distribution of function argument complexity.

> However, I'd still be interested to see an actual statistical survey of the
> effects of CLANG_REVERSE_ARGS
> <http://stackoverflow.com/questions/28570758/can-i-change-the-order-of-argu
> ment-evaluation-in-clang> on a real codebase. Or, even better, a
> statistical survey using some (currently hypothetical) compiler that would
> change its order of evaluation based on some heuristic such as "minimize
> register pressure" or "minimize memory loads".

You don't need a statistical survey to compare RTL to LTR. They will even out,
unless the code you use is specifically geared towards one or the other. It
will be the same with any fixed order of evaluation.

No, the real point, as you finally write, is the comparision between what is
proposed (fixed LTR, say) and what the current standard allows (and a compiler
could, thus, implement, even if they currently don't). And to determine the
latter, absent any compiler actually taking advantage of the freedom, you need
to go and evaluate each function call site by hand. Like "call possibly-
throwing argument evaluations first", "minimize register splilling", ... that
is where you see the potential benefits.

C++ compilers seem to be really bad at optimizing at the C++-specific level. if
I may call it that way, as opposed to at the language-agnostic, intermediate
abstraction levek. GCC doesn't even implement NRVO except in trivial cases.
Pretty poor of an important compiler for something Lawrence Crowl called "the
most important C++ optimisation".

It's a dummy argument to ask for undefined evaluation of function arguments to
be removed from the language just because compilers today are not exploiting
it. They hopefully will, at some point. And when they do, they will break a
lot of broken programs. Just as they always have when gearing up on the
optimization side, e.g. the infamous bugs in the Linux kernel:

   https://lwn.net/Articles/575563/
   https://lwn.net/Articles/278137/
   https://lwn.net/Articles/342330/

In the end, the dust settles, and we're happy that the compilers optimize our
code better and we have learned another way of not breaking our programs.

(as an aside: the GCC warning for when code is removed due to UB is really,
really, annoying, because you cannot work around it, so I believe compiler
writers when they say that you (the programmer) really, really want these
optimisations and you really, really, don't want a warning each time).

Thanks,
Marc

--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts

.

------=_Part_54_2138583215.1451317255980
Content-Type: multipart/alternative;
 boundary="----=_Part_55_1370921551.1451317255980"

------=_Part_55_1370921551.1451317255980
Content-Type: text/plain; charset=UTF-8

On Monday, December 28, 2015 at 3:25:15 AM UTC-5, Marc Mutz wrote:
>
> On Saturday 26 December 2015 00:32:41 Arthur O'Dwyer wrote:
> > >> Notice that while current vendors' rules are certainly *complicated
> and
> > >> confusing*, all evidence so far points to the theory that they are
> > >> *immutable*. I haven't seen an implementation actually change its
> > >> order-of-evaluation rules in order to exploit an optimization
> >
> > opportunity.
> >
> > > Indeed, at least in the absence of further optimisation hints, like
> >
> > [[pure]],
> >
> > > __attribute__((pure)) and __attribute__((const)).
> >
> > This is progress! :)
> > The goalposts have moved now from a broad and easily falsifiable "does
> LTR
> > affect the performance of typical code" (no, according to the evidence
> it
> > seems that it doesn't) to a much more distant and easier-to-ignore "is
> it
> > even *possible*, perhaps through the use of compiler extensions and
> > attributes such as [[pure]], to construct a case where LTR affects
> > performance?"
>
> The discussion on optimizability, from an observer's pov, was never about
> fixed
> RTL vs. LTR. Obviously, they have the same performance on average, given a
> uniform distribution of function argument complexity.
>
> > However, I'd still be interested to see an actual statistical survey of
> the
> > effects of CLANG_REVERSE_ARGS
> > <
> http://stackoverflow.com/questions/28570758/can-i-change-the-order-of-argu
> > ment-evaluation-in-clang> on a real codebase. Or, even better, a
> > statistical survey using some (currently hypothetical) compiler that
> would
> > change its order of evaluation based on some heuristic such as "minimize
> > register pressure" or "minimize memory loads".
>
> You don't need a statistical survey to compare RTL to LTR. They will even
> out,
> unless the code you use is specifically geared towards one or the other.
> It
> will be the same with any fixed order of evaluation.
>
> No, the real point, as you finally write, is the comparision between what
> is
> proposed (fixed LTR, say) and what the current standard allows (and a
> compiler
> could, thus, implement, even if they currently don't). And to determine
> the
> latter, absent any compiler actually taking advantage of the freedom, you
> need
> to go and evaluate each function call site by hand. Like "call possibly-
> throwing argument evaluations first", "minimize register splilling", ...
> that
> is where you see the potential benefits.
>
> C++ compilers seem to be really bad at optimizing at the C++-specific
> level. if
> I may call it that way, as opposed to at the language-agnostic,
> intermediate
> abstraction levek. GCC doesn't even implement NRVO except in trivial
> cases.
> Pretty poor of an important compiler for something Lawrence Crowl called
> "the
> most important C++ optimisation".
>
> It's a dummy argument to ask for undefined evaluation of function
> arguments to
> be removed from the language just because compilers today are not
> exploiting
> it.


The argument is not that we should remove it "just because compilers today
are not exploiting it". The argument is that, "because compilers today are
not exploiting it", we are *free* to remove it. We won't be making any
actual code slower by removing it; we won't be hurting any performance that
code today is relying on.

This is a counter-argument to the claim that ordering evaluations will make
code slower. It will make nobody's code slower, today.

So the only objective downside of ordering evaluations is that it prevents
an optimization that compilers do not currently make.


> They hopefully will, at some point. And when they do, they will break a
> lot of broken programs.


This is not about breaking programs. Again, we're not removing a potential
optimization for its own sake. It's a question of having a language that
makes sense vs. an optimization that isn't even being used.

Sacrificing a potential optimization that isn't being taken advantage of is
a price I'm willing to pay to get a language that makes more sense.

Just as they always have when gearing up on the
> optimization side, e.g. the infamous bugs in the Linux kernel:
>
>    https://lwn.net/Articles/575563/
>    https://lwn.net/Articles/278137/
>    https://lwn.net/Articles/342330/
>
> In the end, the dust settles, and we're happy that the compilers optimize
> our
> code better and we have learned another way of not breaking our programs.
>

Here's the thing. We have compilers now that differ on order of evaluation.
Which means that programs breaking under such changes? That's happening
*now*. The dust? It has already settled.

And yet, people keep making these mistakes. Sometimes they'll linger for
years, silently. And then boom; someone compiles it for a different
compiler with a different ordering. Or whatever. And boom.

So clearly, they have not "learned another way of not breaking our
programs". Why do you think having more arbitrary ordering, based on some
optimization, will help people learn more effectively?

(as an aside: the GCC warning for when code is removed due to UB is really,
> really, annoying, because you cannot work around it, so I believe compiler
> writers when they say that you (the programmer) really, really want these
> optimisations and you really, really, don't want a warning each time).
>
> Thanks,
> Marc
>
> --
> Marc Mutz <marc...@kdab.com <javascript:>> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, December 28, 2015 at 3:25:15 AM UTC-5, Marc Mutz wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">On Saturday 26 December 2015 00:32:41 A=
rthur O&#39;Dwyer wrote:
<br>&gt; &gt;&gt; Notice that while current vendors&#39; rules are certainl=
y *complicated and
<br>&gt; &gt;&gt; confusing*, all evidence so far points to the theory that=
 they are
<br>&gt; &gt;&gt; *immutable*. I haven&#39;t seen an implementation actuall=
y change its
<br>&gt; &gt;&gt; order-of-evaluation rules in order to exploit an optimiza=
tion
<br>&gt;=20
<br>&gt; opportunity.
<br>&gt;=20
<br>&gt; &gt; Indeed, at least in the absence of further optimisation hints=
, like
<br>&gt;=20
<br>&gt; [[pure]],
<br>&gt;=20
<br>&gt; &gt; __attribute__((pure)) and __attribute__((const)).
<br>&gt;=20
<br>&gt; This is progress! :)
<br>&gt; The goalposts have moved now from a broad and easily falsifiable &=
quot;does LTR
<br>&gt; affect the performance of typical code&quot; (no, according to the=
 evidence it
<br>&gt; seems that it doesn&#39;t) to a much more distant and easier-to-ig=
nore &quot;is it
<br>&gt; even *possible*, perhaps through the use of compiler extensions an=
d
<br>&gt; attributes such as [[pure]], to construct a case where LTR affects
<br>&gt; performance?&quot;
<br>
<br>The discussion on optimizability, from an observer&#39;s pov, was never=
 about fixed=20
<br>RTL vs. LTR. Obviously, they have the same performance on average, give=
n a=20
<br>uniform distribution of function argument complexity.
<br>
<br>&gt; However, I&#39;d still be interested to see an actual statistical =
survey of the
<br>&gt; effects of CLANG_REVERSE_ARGS
<br>&gt; &lt;<a href=3D"http://stackoverflow.com/questions/28570758/can-i-c=
hange-the-order-of-argu" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.c=
om%2Fquestions%2F28570758%2Fcan-i-change-the-order-of-argu\46sa\75D\46sntz\=
0751\46usg\75AFQjCNEUn0v9Jl-LKxPlDgBQvZ-slyqAbQ&#39;;return true;" onclick=
=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fstackoverfl=
ow.com%2Fquestions%2F28570758%2Fcan-i-change-the-order-of-argu\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNEUn0v9Jl-LKxPlDgBQvZ-slyqAbQ&#39;;return true;">http=
://stackoverflow.com/<wbr>questions/28570758/can-i-<wbr>change-the-order-of=
-argu</a>
<br>&gt; ment-evaluation-in-clang&gt; on a real codebase. Or, even better, =
a
<br>&gt; statistical survey using some (currently hypothetical) compiler th=
at would
<br>&gt; change its order of evaluation based on some heuristic such as &qu=
ot;minimize
<br>&gt; register pressure&quot; or &quot;minimize memory loads&quot;.
<br>
<br>You don&#39;t need a statistical survey to compare RTL to LTR. They wil=
l even out,=20
<br>unless the code you use is specifically geared towards one or the other=
.. It=20
<br>will be the same with any fixed order of evaluation.
<br>
<br>No, the real point, as you finally write, is the comparision between wh=
at is=20
<br>proposed (fixed LTR, say) and what the current standard allows (and a c=
ompiler=20
<br>could, thus, implement, even if they currently don&#39;t). And to deter=
mine the=20
<br>latter, absent any compiler actually taking advantage of the freedom, y=
ou need=20
<br>to go and evaluate each function call site by hand. Like &quot;call pos=
sibly-
<br>throwing argument evaluations first&quot;, &quot;minimize register spli=
lling&quot;, ... that=20
<br>is where you see the potential benefits.
<br>
<br>C++ compilers seem to be really bad at optimizing at the C++-specific l=
evel. if=20
<br>I may call it that way, as opposed to at the language-agnostic, interme=
diate=20
<br>abstraction levek. GCC doesn&#39;t even implement NRVO except in trivia=
l cases.=20
<br>Pretty poor of an important compiler for something Lawrence Crowl calle=
d &quot;the=20
<br>most important C++ optimisation&quot;.
<br>
<br>It&#39;s a dummy argument to ask for undefined evaluation of function a=
rguments to=20
<br>be removed from the language just because compilers today are not explo=
iting=20
<br>it.</blockquote><div><br>The argument is not that we should remove it &=
quot;just because compilers today are not exploiting it&quot;. The argument=
 is that, &quot;because compilers today are not exploiting it&quot;, we are=
 <i>free</i> to remove it. We won&#39;t be making any actual code slower by=
 removing it; we won&#39;t be hurting any performance that code today is re=
lying on.<br><br>This is a counter-argument to the claim that ordering eval=
uations will make code slower. It will make nobody&#39;s code slower, today=
..<br><br>So the only objective downside of ordering evaluations is that it =
prevents an optimization that compilers do not currently make.<br>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">They hopefully will, at som=
e point. And when they do, they will break a=20
<br>lot of broken programs.</blockquote><div><br>This is not about breaking=
 programs. Again, we&#39;re not removing a potential optimization for its o=
wn sake. It&#39;s a question of having a language that makes sense vs. an o=
ptimization that isn&#39;t even being used.<br><br>Sacrificing a potential =
optimization that isn&#39;t being taken advantage of is a price I&#39;m wil=
ling to pay to get a language that makes more sense.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">Just as they always have when gearing u=
p on the=20
<br>optimization side, e.g. the infamous bugs in the Linux kernel:
<br>
<br>=C2=A0 =C2=A0<a href=3D"https://lwn.net/Articles/575563/" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.co=
m/url?q\75https%3A%2F%2Flwn.net%2FArticles%2F575563%2F\46sa\75D\46sntz\0751=
\46usg\75AFQjCNGzQ1OAWmejudDJc0Wjh92jjnETHw&#39;;return true;" onclick=3D"t=
his.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Flwn.net%2FArti=
cles%2F575563%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNGzQ1OAWmejudDJc0Wjh92jj=
nETHw&#39;;return true;">https://lwn.net/Articles/<wbr>575563/</a>
<br>=C2=A0 =C2=A0<a href=3D"https://lwn.net/Articles/278137/" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.co=
m/url?q\75https%3A%2F%2Flwn.net%2FArticles%2F278137%2F\46sa\75D\46sntz\0751=
\46usg\75AFQjCNHmlBPnmq620OWrGz430K4TTqNyWw&#39;;return true;" onclick=3D"t=
his.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Flwn.net%2FArti=
cles%2F278137%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHmlBPnmq620OWrGz430K4TT=
qNyWw&#39;;return true;">https://lwn.net/Articles/<wbr>278137/</a>
<br>=C2=A0 =C2=A0<a href=3D"https://lwn.net/Articles/342330/" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.co=
m/url?q\75https%3A%2F%2Flwn.net%2FArticles%2F342330%2F\46sa\75D\46sntz\0751=
\46usg\75AFQjCNEgeeD7TKaNwSdX0WOGIIe5JTf6PQ&#39;;return true;" onclick=3D"t=
his.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Flwn.net%2FArti=
cles%2F342330%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEgeeD7TKaNwSdX0WOGIIe5J=
Tf6PQ&#39;;return true;">https://lwn.net/Articles/<wbr>342330/</a>
<br>
<br>In the end, the dust settles, and we&#39;re happy that the compilers op=
timize our=20
<br>code better and we have learned another way of not breaking our program=
s.<br></blockquote><div><br>Here&#39;s the thing. We have compilers now tha=
t differ on order of evaluation. Which means that programs breaking under s=
uch changes? That&#39;s happening <i>now</i>. The dust? It has already sett=
led.<br><br>And yet, people keep making these mistakes. Sometimes they&#39;=
ll linger for years, silently. And then boom; someone compiles it for a dif=
ferent compiler with a different ordering. Or whatever. And boom.<br><br>So=
 clearly, they have not &quot;learned another way of not breaking our progr=
ams&quot;. Why do you think having more arbitrary ordering, based on some o=
ptimization, will help people learn more effectively?<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">
(as an aside: the GCC warning for when code is removed due to UB is really,=
=20
<br>really, annoying, because you cannot work around it, so I believe compi=
ler=20
<br>writers when they say that you (the programmer) really, really want the=
se=20
<br>optimisations and you really, really, don&#39;t want a warning each tim=
e).
<br>
<br>Thanks,
<br>Marc
<br>
<br>--=20
<br>Marc Mutz &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"iFmvm5vXEAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">marc...@kdab.com</a>&gt; | Senior Software Engineer
<br>KDAB (Deutschland) GmbH &amp; Co.KG, a KDAB Group Company
<br>Tel: +49-30-521325470
<br>KDAB - The Qt Experts
<br></blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_55_1370921551.1451317255980--
------=_Part_54_2138583215.1451317255980--

.

On 12/28/2015 04:40 PM, Nicol Bolas wrote:
> On Monday, December 28, 2015 at 3:25:15 AM UTC-5, Marc Mutz wrote:
>     C++ compilers seem to be really bad at optimizing at the C++-specific level. if
>     I may call it that way, as opposed to at the language-agnostic, intermediate
>     abstraction levek.

Yes.  There would be quite a bit of optimization potential when
compilers would look "through" uses of std::string, for example,
and avoid intermediate allocations.  Is it worth the effort?  I don't know.

>        GCC doesn't even implement NRVO except in trivial cases.
>     Pretty poor of an important compiler for something Lawrence Crowl called "the
>     most important C++ optimisation".

Hm... Strange. Now that we mandate calling the move constructor (if any)
upon "return", the compiler is already required to discover these situations.

> This is not about breaking programs. Again, we're not removing a
> potential optimization for its own sake. It's a question of having a
> language that makes sense vs. an optimization that isn't even being
> used.
>
> Sacrificing a potential optimization that isn't being taken advantage
> of is a price I'm willing to pay to get a language that makes more
> sense.

Well, we were at exactly that point regarding type-based alias
analysis about two decades ago or so.  Nowadays, everybody does it,
and it's great for performance.  (Every time I do text parsing and
look at the generated assembly, I curse the time in distant history
when "char" (not just "unsigned char") was made to alias anything,
preventing "obvious" optimizations.  I've been told "the ship has
sailed" 10 years ago or so when I asked to reconsider that decision.)

What if we had removed the option for type-based alias analysis back then?

So, as a member of the committee, I'll tread carefully here.
I do recognize the arguments brought forward for more ordering,
but I'm very reluctant to specify left-to-right for everything.
For example, it seems reasonable to require left-to-right ordering
for class member access, i.e.  x.y  and  x->y.
I notice that the proposal currently on the table limits ordering
to a small number of cases.  I'd like to discuss these cases
one-by-one.

> Here's the thing. We have compilers now that differ on order of
> evaluation. Which means that programs breaking under such changes?
> That's happening /now/. The dust? It has already settled.

At least for portable programs.  For programs that rely on their
compiler's behavior, the dust storm will come once their compiler
switches to the new standard ordering.

Jens

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_6259_1113689014.1451341584250
Content-Type: multipart/alternative;
 boundary="----=_Part_6260_1505901632.1451341584250"

------=_Part_6260_1505901632.1451341584250
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 29, 2015 at 8:11:31 AM UTC+10, Jens Maurer wrote:


> I notice that the proposal currently on the table limits ordering
> to a small number of cases.  I'd like to discuss these cases
> one-by-one.
>

I'm feeling intensely uncomfortable about the current proposal because of
its complexity. Right now, at least we have a simple rule: "evaluation
order is undefined." If left-to-right evaluation were adopted, we'd also
have a simple rule: "evaluation order is left to right." But requiring
left-to-right evaluation in only a subset of the possible scenarios makes
things more complicated and harder to get right.

The last thing C++ needs is yet more complex rules; personally, I'd be
happier with undefined evaluation order than with partially defined
evaluation order, because that's at least easy to remember. Of course,
completely defined evaluation order would be even better because it would
create a simple rule that would eliminate a subtle source of errors.

Michi.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Tuesday, December 29, 2015 at 8:11:31 AM UTC+10, Jens M=
aurer wrote:<div>=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;">I=
 notice that the proposal currently on the table limits ordering
<br>to a small number of cases. =C2=A0I&#39;d like to discuss these cases
<br>one-by-one.
<br></blockquote><div><br></div><div>I&#39;m feeling intensely uncomfortabl=
e about the current proposal because of its complexity. Right now, at least=
 we have a simple rule: &quot;evaluation order is undefined.&quot; If left-=
to-right evaluation were adopted, we&#39;d also have a simple rule: &quot;e=
valuation order is left to right.&quot; But requiring left-to-right evaluat=
ion in only a subset of the possible scenarios makes things more complicate=
d and harder to get right.</div><div><br></div><div>The last thing C++ need=
s is yet more complex rules; personally, I&#39;d be happier with undefined =
evaluation order than with partially defined evaluation order, because that=
&#39;s at least easy to remember. Of course, completely defined evaluation =
order would be even better because it would create a simple rule that would=
 eliminate a subtle source of errors.</div><div><br></div><div>Michi.</div>=
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_6260_1505901632.1451341584250--
------=_Part_6259_1113689014.1451341584250--

.

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

On Mon, Dec 28, 2015 at 2:11 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> On 12/28/2015 04:40 PM, Nicol Bolas wrote:
> > On Monday, December 28, 2015 at 3:25:15 AM UTC-5, Marc Mutz wrote:
> >     C++ compilers seem to be really bad at optimizing at the
> C++-specific level. if
> >     I may call it that way, as opposed to at the language-agnostic,
> intermediate
> >     abstraction levek.
>
> Yes.  There would be quite a bit of optimization potential when
> compilers would look "through" uses of std::string, for example,
> and avoid intermediate allocations.  Is it worth the effort?  I don't know.
>
> >        GCC doesn't even implement NRVO except in trivial cases.
> >     Pretty poor of an important compiler for something Lawrence Crowl
> called "the
> >     most important C++ optimisation".
>
> Hm... Strange. Now that we mandate calling the move constructor (if any)
> upon "return", the compiler is already required to discover these
> situations.


There are additional criteria for NRVO to be safe that do not apply to the
copy->move transformation. In particular, since the optimization allocates
the NRVO candidate into the return slot, every return-statement within the
scope of the NRVO candidate must return that variable [after relevant
optimizations, which might introduce such opportunities -- in particular,
if you can show that the NRVO candidate is non-escaping and has a trivial
destructor, you can sometimes end its lifetime early and reuse the slot].

> This is not about breaking programs. Again, we're not removing a
> > potential optimization for its own sake. It's a question of having a
> > language that makes sense vs. an optimization that isn't even being
> > used.
> >
> > Sacrificing a potential optimization that isn't being taken advantage
> > of is a price I'm willing to pay to get a language that makes more
> > sense.
>
> Well, we were at exactly that point regarding type-based alias
> analysis about two decades ago or so.  Nowadays, everybody does it,
> and it's great for performance.  (Every time I do text parsing and
> look at the generated assembly, I curse the time in distant history
> when "char" (not just "unsigned char") was made to alias anything,
> preventing "obvious" optimizations.  I've been told "the ship has
> sailed" 10 years ago or so when I asked to reconsider that decision.)
>
> What if we had removed the option for type-based alias analysis back then?
>
> So, as a member of the committee, I'll tread carefully here.
> I do recognize the arguments brought forward for more ordering,
> but I'm very reluctant to specify left-to-right for everything.
> For example, it seems reasonable to require left-to-right ordering
> for class member access, i.e.  x.y  and  x->y.
> I notice that the proposal currently on the table limits ordering
> to a small number of cases.  I'd like to discuss these cases
> one-by-one.
>
> > Here's the thing. We have compilers now that differ on order of
> > evaluation. Which means that programs breaking under such changes?
> > That's happening /now/. The dust? It has already settled.
>
> At least for portable programs.  For programs that rely on their
> compiler's behavior, the dust storm will come once their compiler
> switches to the new standard ordering.
>
> Jens
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1142d87cd16dae0527ffa38b
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, Dec 28, 2015 at 2:11 PM, Jens Maurer <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.net</a>&gt;</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"><span class=3D"">On 12/28/2015 04:40 PM, Ni=
col Bolas wrote:<br>
&gt; On Monday, December 28, 2015 at 3:25:15 AM UTC-5, Marc Mutz wrote:<br>
</span><span class=3D"">&gt;=C2=A0 =C2=A0 =C2=A0C++ compilers seem to be re=
ally bad at optimizing at the C++-specific level. if<br>
&gt;=C2=A0 =C2=A0 =C2=A0I may call it that way, as opposed to at the langua=
ge-agnostic, intermediate<br>
&gt;=C2=A0 =C2=A0 =C2=A0abstraction levek.<br>
<br>
</span>Yes.=C2=A0 There would be quite a bit of optimization potential when=
<br>
compilers would look &quot;through&quot; uses of std::string, for example,<=
br>
and avoid intermediate allocations.=C2=A0 Is it worth the effort?=C2=A0 I d=
on&#39;t know.<br>
<span class=3D""><br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 GCC doesn&#39;t even implement NRVO except =
in trivial cases.<br>
&gt;=C2=A0 =C2=A0 =C2=A0Pretty poor of an important compiler for something =
Lawrence Crowl called &quot;the<br>
&gt;=C2=A0 =C2=A0 =C2=A0most important C++ optimisation&quot;.<br>
<br>
</span>Hm... Strange. Now that we mandate calling the move constructor (if =
any)<br>
upon &quot;return&quot;, the compiler is already required to discover these=
 situations.</blockquote><div><br></div><div>There are additional criteria =
for NRVO to be safe that do not apply to the copy-&gt;move transformation. =
In particular, since the optimization allocates the NRVO candidate into the=
 return slot, every return-statement within the scope of the NRVO candidate=
 must return that variable [after relevant optimizations, which might intro=
duce such opportunities -- in particular, if you can show that the NRVO can=
didate is non-escaping and has a trivial destructor, you can sometimes end =
its lifetime early and reuse the slot].</div><div><br></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=
"><span class=3D"">
&gt; This is not about breaking programs. Again, we&#39;re not removing a<b=
r>
&gt; potential optimization for its own sake. It&#39;s a question of having=
 a<br>
&gt; language that makes sense vs. an optimization that isn&#39;t even bein=
g<br>
&gt; used.<br>
&gt;<br>
&gt; Sacrificing a potential optimization that isn&#39;t being taken advant=
age<br>
&gt; of is a price I&#39;m willing to pay to get a language that makes more=
<br>
&gt; sense.<br>
<br>
</span>Well, we were at exactly that point regarding type-based alias<br>
analysis about two decades ago or so.=C2=A0 Nowadays, everybody does it,<br=
>
and it&#39;s great for performance.=C2=A0 (Every time I do text parsing and=
<br>
look at the generated assembly, I curse the time in distant history<br>
when &quot;char&quot; (not just &quot;unsigned char&quot;) was made to alia=
s anything,<br>
preventing &quot;obvious&quot; optimizations.=C2=A0 I&#39;ve been told &quo=
t;the ship has<br>
sailed&quot; 10 years ago or so when I asked to reconsider that decision.)<=
br>
<br>
What if we had removed the option for type-based alias analysis back then?<=
br>
<br>
So, as a member of the committee, I&#39;ll tread carefully here.<br>
I do recognize the arguments brought forward for more ordering,<br>
but I&#39;m very reluctant to specify left-to-right for everything.<br>
For example, it seems reasonable to require left-to-right ordering<br>
for class member access, i.e.=C2=A0 x.y=C2=A0 and=C2=A0 x-&gt;y.<br>
I notice that the proposal currently on the table limits ordering<br>
to a small number of cases.=C2=A0 I&#39;d like to discuss these cases<br>
one-by-one.<br>
<span class=3D""><br>
&gt; Here&#39;s the thing. We have compilers now that differ on order of<br=
>
&gt; evaluation. Which means that programs breaking under such changes?<br>
</span>&gt; That&#39;s happening /now/. The dust? It has already settled.<b=
r>
<br>
At least for portable programs.=C2=A0 For programs that rely on their<br>
compiler&#39;s behavior, the dust storm will come once their compiler<br>
switches to the new standard ordering.<br>
<span class=3D""><font color=3D"#888888"><br>
Jens<br>
</font></span><div class=3D""><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1142d87cd16dae0527ffa38b--

.

On 2015-12-24 21:08, Arthur O'Dwyer wrote:
> On Thursday, December 24, 2015 at 1:03:28 PM UTC-8, Matthew Woehlke wrote:
>> However, given something like:
>>
>>   a(pow(x, y), sqrt(z), external_function());
>>
>> ...you're going to have an obvious performance penalty from LTR, because
>> now you almost certainly have to spill the first two arguments to the
>> stack, whereas with unspecified order, it's much cheaper to call
>> external_function() first and then use registers to compute the first
>> two arguments.
>
> In that example, you're assuming that x,y,z are global variables, right?

I'm not assuming anything. They should be interpreted only as
placeholders for expressions. They don't need to be "actual globals",
though; class members would also suffice to preclude reordering under
strict as-if, as was noted earlier in the thread. (They could also be
function calls themselves, or something else.)

> (We're also assuming that pow and sqrt are the standard library functions,
> so external_function() couldn't execute something like "pow = otherpow;".)

Actually, the "important" assumption is that they are inlined. (And not
necessarily those exact functions; what matters is that the final first
and second arguments can be computed without a register save/restore, as
that's where you'll see a benefit from reordering.)

> - The "observable side effect" of the above code isn't the order in which
> sqrt() and pow() are called, but rather the time at which "x", "y", and "z"
> are loaded (i.e., before or after calling external_function()).

Exactly.

> - GCC 5.3 evaluates function arguments right-to-left, meaning that it will
> "do the right thing" with your example but "do the wrong thing" (i.e.,
> spill) with a(external_function(), sqrt(x), pow(y,z)).
> - Clang 3.7 evaluates function arguments left-to-right, meaning that it
> will "do the wrong thing" (i.e., spill) with your example but "do the right
> thing" with a(external_function(), sqrt(x), pow(y,z)).

Heh... room for improvement :-). But not possible if order of evaluation
becomes specified, which is why folks are being vocal about this.

> - if you think you're getting optimizations like that today, under today's
> rules, you're definitely wrong;

....which is sort of the point others were making... just because we're
not taking as much advantage of unspecified order *now* doesn't mean we
won't in the future. That is, if there is still unspecified order to be
leveraged for performance gains. IOW, we would be cutting off avenues
for future optimization.

> - if you think GCC and Clang will ever agree on the behavior of that code
> (in the absence of pressure from the Standard), you're probably wrong.

Is this a problem? Given unspecified order, one of the points of the
example is that it should be entirely reasonable that the order of
evaluation depends on not only the compiler, but the optimization level
requested.

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-12-24 21:08, Arthur O'Dwyer wrote:

> - GCC 5.3 evaluates function arguments right-to-left, meaning that it wil=
l
>
> "do the right thing" with your example but "do the wrong thing" (i.e.,
> > spill) with a(external_function(), sqrt(x), pow(y,z)).
> > - Clang 3.7 evaluates function arguments left-to-right, meaning that it
> > will "do the wrong thing" (i.e., spill) with your example but "do the
> right
> > thing" with a(external_function(), sqrt(x), pow(y,z)).
>
> Heh... room for improvement :-). But not possible if order of evaluation
> becomes specified, which is why folks are being vocal about this.
>
> > - if you think you're getting optimizations like that today, under
> today's
> > rules, you're definitely wrong;
>
> ...which is sort of the point others were making... just because we're
> not taking as much advantage of unspecified order *now* doesn't mean we
> won't in the future. That is, if there is still unspecified order to be
> leveraged for performance gains. IOW, we would be cutting off avenues
> for future optimization.
>

I agree.
However, like Nicol Bolas, I think that the huge productivity benefits of
having a defined order of evaluation for function arguments (even better:
for all expressions) will benefit humanity *vastly* more than this
particular "avenue for future optimization."

I mean, there are only a finite number of Clang developers, right? Which
feature would you rather they spend time on: optimizations in general, or
an evaluation-order sanitizer in particular? Because under the *current*
state of affairs, we're basically telling them they *have* to write an
evaluation-order sanitizer, just in order to detect and diagnose all the
buggy non-portable code that our fellow software engineers are writing
every day. If we could just nail down the evaluation order in the standard,
so that it became defined and portable, then that problem would completely
go away =E2=80=94 no Clang developer would have to spend a minute longer on=
 that
particular sanitizer =E2=80=94 and they could turn their efforts away from
"cleaning up after C++'s messes" and back toward "writing neat codegen
optimizations." ;)

There's always room for more compiler optimization, under the as-if rule
(this is the Full Employment Theorem for Compiler-Writers
<https://en.wikipedia.org/wiki/Full_employment_theorem>).  I predict that
modules, once they get here, will increase the opportunities for compilers
to "see through" inlining, making them better able to optimize even the
code (such as external_function()) that they can't optimize today.



> > - if you think GCC and Clang will ever agree on the behavior of that co=
de
> > (in the absence of pressure from the Standard), you're probably wrong.
>
> Is this a problem? Given unspecified order, one of the points of the
> example is that it should be entirely reasonable that the order of
> evaluation depends on not only the compiler, but the optimization level
> requested.
>

It's a problem for me, as a software engineer. You should see it too. You
showed us a line of C++ code

    a(pow(x, y), sqrt(z), external_function());

and predicted confidently that the compiler "should" evaluate
external_function() first =E2=80=94 but in fact it didn't, and so your code=
 was
slower than you'd predicted.  Now, if you'd written the code the other way
round,

    a(external_function(), pow(x, y), sqrt(z));

you'd have seen Clang evaluate external_function() first, and so you would
probably have assumed that your prediction matched reality. You'd have left
the code that way in your codebase, and then, six months later, someone
would come to you with a complaint about the code's performance on GCC!

This kind of coding, by "shoulds" and by trial-and-error, *wastes time*.
Let's eliminate trial-and-error. Let's actually define the behavior of the
above piece of code, so that an experienced software engineer such as you
or I can look at the code and not just *guess* at the compiler's
interpretation of it, but actually *know* the interpretation, and then if
the code is wrong, we can fix it =E2=80=94 and have the fix be portable to =
every
implementation, now and forever.

And the best part of this whole proposal is that there's *no tradeoff*. We
don't need to pessimize any existing code to get these benefits. No
existing *valid* code relies on non-LTR evaluation order, and no existing
compiler intentionally evaluates operands in a non-LTR order for
optimization purposes.
A more cynical way to put it is that when you're at the bottom of a hole,
the only way to go is up. We're in the worst possible world right now: the
current standard makes it really easy to write bugs accidentally, and
current compilers don't offer any optimizations to make up for it. So the
*current* state of affairs *has no upside*, which is why LTR-proponents are
so excited to point out that for once we can raise one side of the seesaw
(we can reduce the number of bugs in C++ programs) without lowering the
other (we don't have to lose any existing performance).

=E2=80=93Arthur

P.S. =E2=80=94 The Standard has already constrained order of evaluation mor=
e than I
originally wanted it to, back when I was writing compilers (and had less
experience with other people's bugs). For example, IIRC, in both C and C++
the evaluation of a function body cannot be interleaved with the evaluation
of another function body; i.e.

    inline int b() { return d() + e(); }
    inline int c() { return f() + g(); }
    a(b(), c());

is contrained to produce one of the outputs "defg", "degf", "edfg", "edgf",
"fgde", "fged", "gfde", or "gfed".
The compiler is *not allowed* to produce "dfeg", "dfge", "dgef", "dgfe",
etc., even if that would be more performant.

This was one of my pet peeves circa 2008. However, I've never heard another
compiler writer complain about it. For that matter, I've never heard
another compiler writer talk excitedly about all the optimizations they
could write to take advantage of unspecified-order-of-evaluation rules,
either. ;)

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">=
mwoehlke.floss@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex">On 2015-12-24 21:08, Arthur O=
&#39;Dwyer wrote:</blockquote><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">&gt; - GCC 5.3 evaluates fun=
ction arguments right-to-left, meaning that it will<br></blockquote><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">
&gt; &quot;do the right thing&quot; with your example but &quot;do the wron=
g thing&quot; (i.e.,<br>
&gt; spill) with a(external_function(), sqrt(x), pow(y,z)).<br>
&gt; - Clang 3.7 evaluates function arguments left-to-right, meaning that i=
t<br>
&gt; will &quot;do the wrong thing&quot; (i.e., spill) with your example bu=
t &quot;do the right<br>
&gt; thing&quot; with a(external_function(), sqrt(x), pow(y,z)).<br>
<br>
Heh... room for improvement :-). But not possible if order of evaluation<br=
>
becomes specified, which is why folks are being vocal about this.<br>
<br>
&gt; - if you think you&#39;re getting optimizations like that today, under=
 today&#39;s<br>
&gt; rules, you&#39;re definitely wrong;<br>
<br>
....which is sort of the point others were making... just because we&#39;re<=
br>
not taking as much advantage of unspecified order *now* doesn&#39;t mean we=
<br>
won&#39;t in the future. That is, if there is still unspecified order to be=
<br>
leveraged for performance gains. IOW, we would be cutting off avenues<br>
for future optimization.<br></blockquote><div><br></div><div>I agree.</div>=
<div>However, like Nicol Bolas, I think that the huge productivity benefits=
 of having a defined order of evaluation for function arguments (even bette=
r: for all expressions) will benefit humanity <i>vastly</i> more than this =
particular &quot;avenue for future optimization.&quot;</div><div><br></div>=
<div>I mean, there are only a finite number of Clang developers, right? Whi=
ch feature would you rather they spend time on: optimizations in general, o=
r an evaluation-order sanitizer in particular? Because under the <i>current=
</i> state of affairs, we&#39;re basically telling them they <i>have</i> to=
 write an evaluation-order sanitizer, just in order to detect and diagnose =
all the buggy non-portable code that our fellow software engineers are writ=
ing every day. If we could just nail down the evaluation order in the stand=
ard, so that it became defined and portable, then that problem would comple=
tely go away =E2=80=94 no Clang developer would have to spend a minute long=
er on that particular sanitizer =E2=80=94 and they could turn their efforts=
 away from &quot;cleaning up after C++&#39;s messes&quot; and back toward &=
quot;writing neat codegen optimizations.&quot; ;)</div><div><br></div><div>=
There&#39;s always room for more compiler optimization, under the as-if rul=
e (this is the <a href=3D"https://en.wikipedia.org/wiki/Full_employment_the=
orem">Full Employment Theorem for Compiler-Writers</a>).=C2=A0 I predict th=
at modules, once they get here, will increase the opportunities for compile=
rs to &quot;see through&quot; inlining, making them better able to optimize=
 even the code (such as external_function()) that they can&#39;t optimize t=
oday.</div><div><br></div><div>=C2=A0<br></div><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">&gt; - if y=
ou think GCC and Clang will ever agree on the behavior of that code<br>
&gt; (in the absence of pressure from the Standard), you&#39;re probably wr=
ong.<br>
<br>
Is this a problem? Given unspecified order, one of the points of the<br>
example is that it should be entirely reasonable that the order of<br>
evaluation depends on not only the compiler, but the optimization level<br>
requested.<br></blockquote><div><br></div><div>It&#39;s a problem for me, a=
s a software engineer. You should see it too. You showed us a line of C++ c=
ode=C2=A0</div><div><br></div><div>=C2=A0 =C2=A0 a(pow(x, y), sqrt(z), exte=
rnal_function());<br></div><div><br></div><div>and predicted confidently th=
at the compiler &quot;should&quot; evaluate external_function() first =E2=
=80=94 but in fact it didn&#39;t, and so your code was slower than you&#39;=
d predicted.=C2=A0 Now, if you&#39;d written the code the other way round,<=
/div><div><br></div><div>=C2=A0 =C2=A0 a(external_function(), pow(x, y), sq=
rt(z));<br></div><div><br></div><div>you&#39;d have seen Clang evaluate ext=
ernal_function() first, and so you would probably have assumed that your pr=
ediction matched reality. You&#39;d have left the code that way in your cod=
ebase, and then, six months later, someone would come to you with a complai=
nt about the code&#39;s performance on GCC!</div><div><br></div><div>This k=
ind of coding, by &quot;shoulds&quot; and by trial-and-error,=C2=A0<i>waste=
s time</i>. Let&#39;s eliminate trial-and-error. Let&#39;s actually define =
the behavior of the above piece of code, so that an experienced software en=
gineer such as you or I can look at the code and not just <i>guess</i> at t=
he compiler&#39;s interpretation of it, but actually <i>know</i> the interp=
retation, and then if the code is wrong, we can fix it =E2=80=94 and have t=
he fix be portable to every implementation, now and forever.</div><div><br>=
</div><div>And the best part of this whole proposal is that there&#39;s <i>=
no tradeoff</i>. We don&#39;t need to pessimize any existing code to get th=
ese benefits. No existing <i>valid</i> code relies on non-LTR evaluation or=
der, and no existing compiler intentionally evaluates operands in a non-LTR=
 order for optimization purposes.</div><div>A more cynical way to put it is=
 that when you&#39;re at the bottom of a hole, the only way to go is up. We=
&#39;re in the worst possible world right now: the current standard makes i=
t really easy to write bugs accidentally, and current compilers don&#39;t o=
ffer any optimizations to make up for it. So the <i>current</i> state of af=
fairs <i>has no upside</i>, which is why LTR-proponents are so excited to p=
oint out that for once we can raise one side of the seesaw (we can reduce t=
he number of bugs in C++ programs) without lowering the other (we don&#39;t=
 have to lose any existing performance).</div><div><br></div><div>=E2=80=93=
Arthur</div><div><br></div><div>P.S. =E2=80=94 The Standard has already con=
strained order of evaluation more than I originally wanted it to, back when=
 I was writing compilers (and had less experience with other people&#39;s b=
ugs). For example, IIRC, in both C and C++ the evaluation of a function bod=
y cannot be interleaved with the evaluation of another function body; i.e.<=
/div><div><br></div><div>=C2=A0 =C2=A0 inline int b() { return d() + e(); }=
<br></div><div>=C2=A0 =C2=A0 inline int c() { return f() + g(); }</div><div=
>=C2=A0 =C2=A0 a(b(), c());</div><div><br></div><div>is contrained to produ=
ce one of the outputs &quot;defg&quot;, &quot;degf&quot;, &quot;edfg&quot;,=
 &quot;edgf&quot;, &quot;fgde&quot;, &quot;fged&quot;, &quot;gfde&quot;, or=
 &quot;gfed&quot;.</div><div>The compiler is <i>not allowed</i> to produce =
&quot;dfeg&quot;, &quot;dfge&quot;, &quot;dgef&quot;, &quot;dgfe&quot;, etc=
.., even if that would be more performant.</div><div><br></div><div>This was=
 one of my pet peeves circa 2008. However, I&#39;ve never heard another com=
piler writer complain about it. For that matter, I&#39;ve never heard anoth=
er compiler writer talk excitedly about all the optimizations they could wr=
ite to take advantage of unspecified-order-of-evaluation rules, either. ;)<=
/div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a11420926478b9105280f1d7c--

.

On 2015-12-29 15:17, Arthur O'Dwyer wrote:
> On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke wrote:
>> On 2015-12-24 21:08, Arthur O'Dwyer wrote:
>>> - if you think GCC and Clang will ever agree on the behavior of that co=
de
>>> (in the absence of pressure from the Standard), you're probably wrong.
>>
>> Is this a problem? Given unspecified order, one of the points of the
>> example is that it should be entirely reasonable that the order of
>> evaluation depends on not only the compiler, but the optimization level
>> requested.
>=20
> It's a problem for me, as a software engineer. You should see it too.

I only see a problem when code has non-obvious side effects. Which, to
me, indicates poorly written code.

I also don't see modules as being a "silver bullet" to better
optimization under provable as-if. My impression from LTO is that whole
program optimization is hard. I don't see how modules are going to
magically do better. (I suppose the argument would be that modules
aren't LTO, but better compiler "documentation" of side effects... but
then, where does this "documentation" come from? Who writes the code to
produce it?)

> You showed us a line of C++ code
>=20
>     a(pow(x, y), sqrt(z), external_function());
>=20
> and predicted confidently that the compiler "should" evaluate
> external_function() first =E2=80=94 but in fact it didn't, and so your co=
de was
> slower than you'd predicted.

I made no such prediction (not explicitly, nor was such intended). I
only stated that it would be more efficient to do so.

> Now, if you'd written the code the other way round,
>=20
>     a(external_function(), pow(x, y), sqrt(z));
>=20
> you'd have seen Clang evaluate external_function() first, and so you woul=
d
> probably have assumed that your prediction matched reality. You'd have le=
ft
> the code that way in your codebase, and then, six months later, someone
> would come to you with a complaint about the code's performance on GCC!
>=20
> This kind of coding, by "shoulds" and by trial-and-error, *wastes time*.

If that's how you approach optimization, I'd say you're doing it wrong.
(Besides, if that scenario actually happened, I'd probably file a missed
optimization bug with GCC. Or with clang, the other way around.)

> Let's eliminate trial-and-error. Let's actually define the behavior of th=
e
> above piece of code, so that an experienced software engineer such as you
> or I can look at the code and not just *guess* at the compiler's
> interpretation of it, but actually *know* the interpretation, and then if
> the code is wrong, we can fix it =E2=80=94 and have the fix be portable t=
o every
> implementation, now and forever.

If a particular spot of code is really so critical path that it *relies*
on this specific optimization, it should be written in a way that
ensures the optimization. Possibly by writing it in assembly.

I think you're missing the forest for the trees. The point isn't that
one very specific optimization is made or not. The point is that
programming and optimization is about a balance of expressed intent to
allowed behavior. The more latitude is left to compilers, the more room
there is for them to produce better code.

> And the best part of this whole proposal is that there's *no tradeoff*. W=
e
> don't need to pessimize any existing code to get these benefits.

Except we're doing *exactly that*. We're saying that existing code that
is correct regardless of order of execution must now be evaluated in a
specific order, even if that order is less efficient than the optimal
order, or even existing order.

Is the cost of actual or potential lost performance of existing code,
plus the burden of having to spell out order of evaluation (e.g. by use
of additional temporaries) where it is known to matter, worth the
benefit of not accidentally writing bad code?

I don't know. Maybe. However, I remain unconvinced that it is.

> A more cynical way to put it is that when you're at the bottom of a hole,
> the only way to go is up. We're in the worst possible world right now: th=
e
> current standard makes it really easy to write bugs accidentally, and
> current compilers don't offer any optimizations to make up for it.

I'm curious how this is different from the situation with aliasing. It's
an interesting parallel to which I don't see any of those favoring the
proposal offering any response.

--=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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

------=_Part_4402_1855670298.1451455090638
Content-Type: multipart/alternative;
 boundary="----=_Part_4403_707522577.1451455090638"

------=_Part_4403_707522577.1451455090638
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 29, 2015 at 4:05:34 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-12-29 15:17, Arthur O'Dwyer wrote:
> > And the best part of this whole proposal is that there's *no tradeoff*.
> We
> > don't need to pessimize any existing code to get these benefits.
>
> Except we're doing *exactly that*. We're saying that existing code that
> is correct regardless of order of execution must now be evaluated in a
> specific order, even if that order is less efficient than the optimal
> order, or even existing order.



Is the cost of actual or potential lost performance of existing code,
> plus the burden of having to spell out order of evaluation (e.g. by use
> of additional temporaries) where it is known to matter, worth the
> benefit of not accidentally writing bad code?
>

Yes, yes, a thousand times yes!

The theoretical potential lost cost of ANY potential optimization is worth
the price of avoiding incorrect behavior, especially when that optimization
is not something that anyone is doing, so there is no actual cost for
existing correct code.  As shown in this thread, two of the major compilers
choose opposite orders, so unless you're writing only to one compiler, you
are already getting the non-optimal order, if there is such a thing.

You already have to use temporaries for where order of execution does
matter, as there is no other way to define the order of execution.
This doesn't change that in the least.  The only way to avoid the
temporaries
where it matters is to specify the order of evaluation.

I am reminded of some CppCon talks from this year and last year.

CppCon 2015, Herb Sutter
"Writing Good C++14... By Default"

The goal is that "C++ Code compiled in the safe subset is never the
root cause of type/memory safety errors, except where explicitly annotated
as unsafe".

Writing a function with multiple parameters should be part of that safe
subset.
We shouldn't have to create temporaries and make our code harder to read
just to make the code safe, and get the types of those temporaries right so
that we don't have unnecessary copies, or then deal with dangling
references.


CppCon 2014, Herb Sutter, final session
"Back to the Basics! Essentials of Modern C++ Style"

"Hi, my name is Herb.  ...  Today I want to talk about the importance of
resisting complexity.  ...  People that are under the influence of
complexity
often think that they're thinking more lucidly ... we get so used to
complexity ... once you know a lot about anything, including C++, it's
really
hard to forget that you're an expert.  ...  We need to give good guidance to
the big circle."

There are roughly 3 million professional C++ developers out there.
If we experts can't even get this right, how are they expected to do so?


CppCon 2015, Kate Gregory, "Stop teaching C"

People use other languages because they think C++ is too hard to learn.
If we have to teach them that order of evaluation is undefined, but in other
languages it's not, it's just another thing that makes C++ "hard to learn".

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Tuesday, December 29, 2015 at 4:05:34 PM UTC-5, Matthew Woehlke wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-29 15:17, Arthur O&#3=
9;Dwyer wrote:
<br>&gt; And the best part of this whole proposal is that there&#39;s *no t=
radeoff*. We
<br>&gt; don&#39;t need to pessimize any existing code to get these benefit=
s.
<br>
<br>Except we&#39;re doing *exactly that*. We&#39;re saying that existing c=
ode that
<br>is correct regardless of order of execution must now be evaluated in a
<br>specific order, even if that order is less efficient than the optimal
<br>order, or even existing order.=C2=A0</blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">=C2=A0</blockquote><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">Is the cost of actual or potential lost performance of existing=
 code,
<br>plus the burden of having to spell out order of evaluation (e.g. by use
<br>of additional temporaries) where it is known to matter, worth the
<br>benefit of not accidentally writing bad code?
<br></blockquote><div><br></div><div><div>Yes, yes, a thousand times yes!</=
div><div><br></div><div>The theoretical potential lost cost of ANY potentia=
l optimization is worth</div><div>the price of avoiding incorrect behavior,=
 especially when that optimization</div><div>is not something that anyone i=
s doing, so there is no actual cost for</div><div>existing correct code. =
=C2=A0As shown in this thread, two of the major compilers</div><div>choose =
opposite orders, so unless you&#39;re writing only to one compiler, you</di=
v><div>are already getting the non-optimal order, if there is such a thing.=
</div><div><br></div><div>You already have to use temporaries for where ord=
er of execution does</div><div>matter, as there is no other way to define t=
he order of execution.</div><div>This doesn&#39;t change that in the least.=
 =C2=A0The only way to avoid the temporaries</div><div>where it matters is =
to specify the order of evaluation.</div><div><br></div><div>I am reminded =
of some CppCon talks from this year and last year.</div><div><br></div><div=
>CppCon 2015, Herb Sutter</div><div>&quot;Writing Good C++14... By Default&=
quot;</div><div><br></div><div>The goal is that &quot;C++ Code compiled in =
the safe subset is never the</div><div>root cause of type/memory safety err=
ors, except where explicitly annotated</div><div>as unsafe&quot;.</div><div=
><br></div><div>Writing a function with multiple parameters should be part =
of that safe subset.</div><div>We shouldn&#39;t have to create temporaries =
and make our code harder to read</div><div>just to make the code safe, and =
get the types of those temporaries right so</div><div>that we don&#39;t hav=
e unnecessary copies, or then deal with dangling references.</div><div><br>=
</div><div><br></div><div>CppCon 2014, Herb Sutter, final session</div><div=
>&quot;Back to the Basics! Essentials of Modern C++ Style&quot;</div><div><=
br></div><div>&quot;Hi, my name is Herb. =C2=A0... =C2=A0Today I want to ta=
lk about the importance of=C2=A0</div><div>resisting complexity. =C2=A0... =
=C2=A0People that are under the influence of complexity</div><div>often thi=
nk that they&#39;re thinking more lucidly ... we get so used to=C2=A0</div>=
<div>complexity ... once you know a lot about anything, including C++, it&#=
39;s really</div><div>hard to forget that you&#39;re an expert. =C2=A0... =
=C2=A0We need to give good guidance to</div><div>the big circle.&quot;</div=
><div><br></div><div>There are roughly 3 million professional C++ developer=
s out there.</div><div>If we experts can&#39;t even get this right, how are=
 they expected to do so?</div><div><br></div><div><br></div><div>CppCon 201=
5, Kate Gregory, &quot;Stop teaching C&quot;</div><div><br></div><div>Peopl=
e use other languages because they think C++ is too hard to learn.</div><di=
v>If we have to teach them that order of evaluation is undefined, but in ot=
her</div><div>languages it&#39;s not, it&#39;s just another thing that make=
s C++ &quot;hard to learn&quot;.</div></div><div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_4403_707522577.1451455090638--
------=_Part_4402_1855670298.1451455090638--

.

On Tue, Dec 29, 2015 at 11:58 PM, Greg Marr <gregmmarr@gmail.com> wrote:
> CppCon 2015, Herb Sutter
> "Writing Good C++14... By Default"
>
> The goal is that "C++ Code compiled in the safe subset is never the
> root cause of type/memory safety errors, except where explicitly annotated
> as unsafe".

If there is no explicit `new` in a program, then the memory
safety is guaranteed, thus the goal is achieved.

> Writing a function with multiple parameters should be part of that safe
> subset.

If not interacting with `new`, order of evaluation causes no
type/memory safety issues.  There might be logic issues
though; whose fault is that would be another topic.

> We shouldn't have to create temporaries and make our code harder to read
> just to make the code safe, and get the types of those temporaries right so
> that we don't have unnecessary copies, or then deal with dangling
> references.

If the function calls as arguments return something while
making side-effects, I think it's fair to proceed one mission
at one time.

> There are roughly 3 million professional C++ developers out there.
> If we experts can't even get this right, how are they expected to do so?

No choice has been defined as "right" yet.

> CppCon 2015, Kate Gregory, "Stop teaching C"
>
> People use other languages because they think C++ is too hard to learn.
> If we have to teach them that order of evaluation is undefined, but in other
> languages it's not, it's just another thing that makes C++ "hard to learn".

Different people have different opinions.  For example,
she also considers iostream as "easy to learn" :(

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-12-29 21:17, Arthur O'Dwyer wrote:
> On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke
> <mwoehlke.floss@gmail.com <mailto:mwoehlke.floss@gmail.com>> wrote:
>
>     On 2015-12-24 21:08, Arthur O'Dwyer wrote:
>
>      > - GCC 5.3 evaluates function arguments right-to-left, meaning
>     that it will
>
>      > "do the right thing" with your example but "do the wrong thing"
>     (i.e.,
>      > spill) with a(external_function(), sqrt(x), pow(y,z)).
>      > - Clang 3.7 evaluates function arguments left-to-right, meaning
>     that it
>      > will "do the wrong thing" (i.e., spill) with your example but "do
>     the right
>      > thing" with a(external_function(), sqrt(x), pow(y,z)).
>
>     Heh... room for improvement :-). But not possible if order of evaluat=
ion
>     becomes specified, which is why folks are being vocal about this.
>
>      > - if you think you're getting optimizations like that today,
>     under today's
>      > rules, you're definitely wrong;
>
>     ...which is sort of the point others were making... just because we'r=
e
>     not taking as much advantage of unspecified order *now* doesn't mean =
we
>     won't in the future. That is, if there is still unspecified order to =
be
>     leveraged for performance gains. IOW, we would be cutting off avenues
>     for future optimization.
>
>
> I agree.
> However, like Nicol Bolas, I think that the huge productivity benefits
> of having a defined order of evaluation for function arguments (even
> better: for all expressions) will benefit humanity /vastly/ more than
> this particular "avenue for future optimization."
>
> I mean, there are only a finite number of Clang developers, right? Which
> feature would you rather they spend time on: optimizations in general,
> or an evaluation-order sanitizer in particular? Because under the
> /current/ state of affairs, we're basically telling them they /have/ to
> write an evaluation-order sanitizer, just in order to detect and
> diagnose all the buggy non-portable code that our fellow software
> engineers are writing every day. If we could just nail down the
> evaluation order in the standard, so that it became defined and
> portable, then that problem would completely go away =E2=80=94 no Clang
> developer would have to spend a minute longer on that particular
> sanitizer =E2=80=94 and they could turn their efforts away from "cleaning=
 up
> after C++'s messes" and back toward "writing neat codegen optimizations."=
 ;)
>

I don't see this as a clear win. By specifying the order of evaluation,=20
you have added a limitation for the optimizer. Writing it now has become=20
HARDER, not easier.

It might in fact take more time getting the optimizer back on track than=20
it would have taken writing the sanitizer.


Bo Persson



--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

------=_Part_5023_209268684.1451502590996
Content-Type: multipart/alternative;
 boundary="----=_Part_5024_291455637.1451502590996"

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

On Wednesday, December 30, 2015 at 5:06:09 AM UTC-5, Bo Persson wrote:
>
> On 2015-12-29 21:17, Arthur O'Dwyer wrote:=20
> > On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke=20
> > <mwoehlk...@gmail.com <javascript:> <mailto:mwoehlk...@gmail.com=20
> <javascript:>>> wrote:=20
> >=20
> >     On 2015-12-24 21:08, Arthur O'Dwyer wrote:=20
> >=20
> >      > - GCC 5.3 evaluates function arguments right-to-left, meaning=20
> >     that it will=20
> >=20
> >      > "do the right thing" with your example but "do the wrong thing"=
=20
> >     (i.e.,=20
> >      > spill) with a(external_function(), sqrt(x), pow(y,z)).=20
> >      > - Clang 3.7 evaluates function arguments left-to-right, meaning=
=20
> >     that it=20
> >      > will "do the wrong thing" (i.e., spill) with your example but "d=
o=20
> >     the right=20
> >      > thing" with a(external_function(), sqrt(x), pow(y,z)).=20
> >=20
> >     Heh... room for improvement :-). But not possible if order of=20
> evaluation=20
> >     becomes specified, which is why folks are being vocal about this.=
=20
> >=20
> >      > - if you think you're getting optimizations like that today,=20
> >     under today's=20
> >      > rules, you're definitely wrong;=20
> >=20
> >     ...which is sort of the point others were making... just because=20
> we're=20
> >     not taking as much advantage of unspecified order *now* doesn't mea=
n=20
> we=20
> >     won't in the future. That is, if there is still unspecified order t=
o=20
> be=20
> >     leveraged for performance gains. IOW, we would be cutting off=20
> avenues=20
> >     for future optimization.=20
> >=20
> >=20
> > I agree.=20
> > However, like Nicol Bolas, I think that the huge productivity benefits=
=20
> > of having a defined order of evaluation for function arguments (even=20
> > better: for all expressions) will benefit humanity /vastly/ more than=
=20
> > this particular "avenue for future optimization."=20
> >=20
> > I mean, there are only a finite number of Clang developers, right? Whic=
h=20
> > feature would you rather they spend time on: optimizations in general,=
=20
> > or an evaluation-order sanitizer in particular? Because under the=20
> > /current/ state of affairs, we're basically telling them they /have/ to=
=20
> > write an evaluation-order sanitizer, just in order to detect and=20
> > diagnose all the buggy non-portable code that our fellow software=20
> > engineers are writing every day. If we could just nail down the=20
> > evaluation order in the standard, so that it became defined and=20
> > portable, then that problem would completely go away =E2=80=94 no Clang=
=20
> > developer would have to spend a minute longer on that particular=20
> > sanitizer =E2=80=94 and they could turn their efforts away from "cleani=
ng up=20
> > after C++'s messes" and back toward "writing neat codegen=20
> optimizations." ;)=20
> >=20
>
> I don't see this as a clear win. By specifying the order of evaluation,=
=20
> you have added a limitation for the optimizer. Writing it now has become=
=20
> HARDER, not easier.=20
>

That would only be true for an optimizer that actually reordered=20
evaluations. Pretty strong evidence has already been presented that Clang=
=20
and GCC *don't* reorder expressions optimially. That they have a=20
consistent, fixed evaluation order.

They just don't have the *same* order. As such, enforcing a specific order=
=20
will make nothing "HARDER".

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

On Wednesday, December 30, 2015 at 5:06:09 AM UTC-5, Bo Persson wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On 2015-12-29 21:17, Arthur O&#39;D=
wyer wrote:
<br>&gt; On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke
<br>&gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"_WGlfkZ6EQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">mwoehlk...@gmail.com</a> &lt;mailto:<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"_WGlfkZ6EQAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">mwoehlk...@gmail.<wbr>com</a>&gt;&g=
t; wrote:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 On 2015-12-24 21:08, Arthur O&#39;Dwyer wrote:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; - GCC 5.3 evaluates function arguments ri=
ght-to-left, meaning
<br>&gt; =C2=A0 =C2=A0 that it will
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; &quot;do the right thing&quot; with your =
example but &quot;do the wrong thing&quot;
<br>&gt; =C2=A0 =C2=A0 (i.e.,
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; spill) with a(external_function(), sqrt(x=
), pow(y,z)).
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; - Clang 3.7 evaluates function arguments =
left-to-right, meaning
<br>&gt; =C2=A0 =C2=A0 that it
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; will &quot;do the wrong thing&quot; (i.e.=
, spill) with your example but &quot;do
<br>&gt; =C2=A0 =C2=A0 the right
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; thing&quot; with a(external_function(), s=
qrt(x), pow(y,z)).
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 Heh... room for improvement :-). But not possible if=
 order of evaluation
<br>&gt; =C2=A0 =C2=A0 becomes specified, which is why folks are being voca=
l about this.
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; - if you think you&#39;re getting optimiz=
ations like that today,
<br>&gt; =C2=A0 =C2=A0 under today&#39;s
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; rules, you&#39;re definitely wrong;
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 ...which is sort of the point others were making... =
just because we&#39;re
<br>&gt; =C2=A0 =C2=A0 not taking as much advantage of unspecified order *n=
ow* doesn&#39;t mean we
<br>&gt; =C2=A0 =C2=A0 won&#39;t in the future. That is, if there is still =
unspecified order to be
<br>&gt; =C2=A0 =C2=A0 leveraged for performance gains. IOW, we would be cu=
tting off avenues
<br>&gt; =C2=A0 =C2=A0 for future optimization.
<br>&gt;
<br>&gt;
<br>&gt; I agree.
<br>&gt; However, like Nicol Bolas, I think that the huge productivity bene=
fits
<br>&gt; of having a defined order of evaluation for function arguments (ev=
en
<br>&gt; better: for all expressions) will benefit humanity /vastly/ more t=
han
<br>&gt; this particular &quot;avenue for future optimization.&quot;
<br>&gt;
<br>&gt; I mean, there are only a finite number of Clang developers, right?=
 Which
<br>&gt; feature would you rather they spend time on: optimizations in gene=
ral,
<br>&gt; or an evaluation-order sanitizer in particular? Because under the
<br>&gt; /current/ state of affairs, we&#39;re basically telling them they =
/have/ to
<br>&gt; write an evaluation-order sanitizer, just in order to detect and
<br>&gt; diagnose all the buggy non-portable code that our fellow software
<br>&gt; engineers are writing every day. If we could just nail down the
<br>&gt; evaluation order in the standard, so that it became defined and
<br>&gt; portable, then that problem would completely go away =E2=80=94 no =
Clang
<br>&gt; developer would have to spend a minute longer on that particular
<br>&gt; sanitizer =E2=80=94 and they could turn their efforts away from &q=
uot;cleaning up
<br>&gt; after C++&#39;s messes&quot; and back toward &quot;writing neat co=
degen optimizations.&quot; ;)
<br>&gt;
<br>
<br>I don&#39;t see this as a clear win. By specifying the order of evaluat=
ion,=20
<br>you have added a limitation for the optimizer. Writing it now has becom=
e=20
<br>HARDER, not easier.
<br></blockquote><div><br>That would only be true for an optimizer that act=
ually reordered evaluations. Pretty strong evidence has already been presen=
ted that Clang and GCC <i>don&#39;t</i> reorder expressions optimially. Tha=
t they have a consistent, fixed evaluation order.<br><br>They just don&#39;=
t have the <i>same</i> order. As such, enforcing a specific order will make=
 nothing &quot;HARDER&quot;.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_5024_291455637.1451502590996--
------=_Part_5023_209268684.1451502590996--

.

------=_Part_2949_1740791906.1451502947271
Content-Type: multipart/alternative;
 boundary="----=_Part_2950_634190225.1451502947271"

------=_Part_2950_634190225.1451502947271
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 30, 2015 at 2:18:12 AM UTC-5, Zhihao Yuan wrote:
>
> On Tue, Dec 29, 2015 at 11:58 PM, Greg Marr <greg...@gmail.com
> <javascript:>> wrote:
> > CppCon 2015, Herb Sutter
> > "Writing Good C++14... By Default"
> >
> > The goal is that "C++ Code compiled in the safe subset is never the
> > root cause of type/memory safety errors, except where explicitly
> annotated
> > as unsafe".
>
> If there is no explicit `new` in a program, then the memory
> safety is guaranteed, thus the goal is achieved.
>

.... what? I hope you don't genuinely believe that.

And I'm not talking about some pedantic issue like using `malloc` or
whatever. Memory safety can be broken simply by someone storing a
pointer/reference to heap-allocated memory which is later deleted by your
"memory safe" smart pointers.

> There are roughly 3 million professional C++ developers out there.
> > If we experts can't even get this right, how are they expected to do so?
>
> No choice has been defined as "right" yet.
>

Well, if the last 20-odd years of C++ have taught us anything, it's that
"undefined" is the *wrong* answer. Any order that ca be relied on
cross-compiler is better than none.


>
> > CppCon 2015, Kate Gregory, "Stop teaching C"
> >
> > People use other languages because they think C++ is too hard to learn.
> > If we have to teach them that order of evaluation is undefined, but in
> other
> > languages it's not, it's just another thing that makes C++ "hard to
> learn".
>
> Different people have different opinions.  For example,
> she also considers iostream as "easy to learn" :(
>

iostreams *are* easy to learn.

They're just painful to actually use for anything, make writing new
streambufs exceedingly arcane, and have needlessly-terrible performance.
But they're quite easy to learn.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Wednesday, December 30, 2015 at 2:18:12 AM UTC-5, Zhiha=
o Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Dec 29, 2=
015 at 11:58 PM, Greg Marr &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"ejqEPhxxEQAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;">greg...@gmail.com</a>&gt; wrote:
<br>&gt; CppCon 2015, Herb Sutter
<br>&gt; &quot;Writing Good C++14... By Default&quot;
<br>&gt;
<br>&gt; The goal is that &quot;C++ Code compiled in the safe subset is nev=
er the
<br>&gt; root cause of type/memory safety errors, except where explicitly a=
nnotated
<br>&gt; as unsafe&quot;.
<br>
<br>If there is no explicit `new` in a program, then the memory
<br>safety is guaranteed, thus the goal is achieved.
<br></blockquote><div><br>... what? I hope you don&#39;t genuinely believe =
that.<br><br>And I&#39;m not talking about some pedantic issue like using `=
malloc` or whatever. Memory safety can be broken simply by someone storing =
a pointer/reference to heap-allocated memory which is later deleted by your=
 &quot;memory safe&quot; smart pointers.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">
&gt; There are roughly 3 million professional C++ developers out there.
<br>&gt; If we experts can&#39;t even get this right, how are they expected=
 to do so?
<br>
<br>No choice has been defined as &quot;right&quot; yet.
<br></blockquote><div><br>Well, if the last 20-odd years of C++ have taught=
 us anything, it&#39;s that &quot;undefined&quot; is the <i>wrong</i> answe=
r. Any order that ca be relied on cross-compiler is better than none.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; CppCon 2015, Kate Gregory, &quot;Stop teaching C&quot;
<br>&gt;
<br>&gt; People use other languages because they think C++ is too hard to l=
earn.
<br>&gt; If we have to teach them that order of evaluation is undefined, bu=
t in other
<br>&gt; languages it&#39;s not, it&#39;s just another thing that makes C++=
 &quot;hard to learn&quot;.
<br>
<br>Different people have different opinions. =C2=A0For example,
<br>she also considers iostream as &quot;easy to learn&quot; :(
<br></blockquote><div><br>iostreams <i>are</i> easy to learn.<br><br>They&#=
39;re just painful to actually use for anything, make writing new streambuf=
s exceedingly arcane, and have needlessly-terrible performance. But they&#3=
9;re quite easy to learn.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_2950_634190225.1451502947271--
------=_Part_2949_1740791906.1451502947271--

.

On 2015-12-30 14:09, Nicol Bolas wrote:
> On Wednesday, December 30, 2015 at 5:06:09 AM UTC-5, Bo Persson wrote:
>> I don't see this as a clear win. By specifying the order of evaluation,
>> you have added a limitation for the optimizer. Writing it now has become
>> HARDER, not easier.
>
> That would only be true for an optimizer that actually reordered
> evaluations. Pretty strong evidence has already been presented that Clang
> and GCC *don't* reorder expressions optimially. That they have a
> consistent, fixed evaluation order.
>
> They just don't have the *same* order. As such, enforcing a specific order
> will make nothing "HARDER".

I think you missed the point. Bo is talking about *writing such an
optimizer*.

Right now, the logic such an optimizer would implement is:

- For each possible non-default ordering X, is X more efficient?
  - Yes ==> use ordering X
  - No  ==> keep checking
- No more possible orderings ==> use default ordering

Granted, the first step may be complicated. But consider the logic that
would be necessary under the proposal:

- For each possible non-default ordering X, is X more efficient?
  - Yes ==>
    - Is the result from ordering X equivalent to
      the standard mandated ordering under as-if?
      - Yes ==> use ordering X
      - No  ==> keep checking
  - No  ==> keep checking
- No more possible orderings ==> use standard mandated ordering

(I've simplified; you wouldn't just use the first "better" order, you'd
use the "best", but you get the idea.)

The difference is the second check, which is *also* likely to be
complicated. Bo's point is that writing the second check, which is
necessary under the proposal to *ever* provide the optimization we're
discussing, might be more complicated than writing a sanitizer to warn
if you might be relying on a particular ordering. (This also ignores
that the proposal might also preclude choosing orders that would
otherwise be better choices.)

So... no. "Enforcing" (i.e. enforced but with the as-if exception) a
particular order *will* make something harder.

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

> On 31 Dec 2015, at 5:55 , Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>
> So... no. "Enforcing" (i.e. enforced but with the as-if exception) a
> particular order *will* make something harder.

So, what is preferable? Making the job of the optimizer author harder, which happens once, or making the job of every C++ programmer harder, which happens millions of times?

Michi.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5163_1882241431.1451527483882
Content-Type: multipart/alternative;
 boundary="----=_Part_5164_1598572159.1451527483882"

------=_Part_5164_1598572159.1451527483882
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 30, 2015 at 2:55:55 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-12-30 14:09, Nicol Bolas wrote:
> > On Wednesday, December 30, 2015 at 5:06:09 AM UTC-5, Bo Persson wrote:
> >> I don't see this as a clear win. By specifying the order of evaluation,
> >> you have added a limitation for the optimizer. Writing it now has
> become
> >> HARDER, not easier.
> >
> > That would only be true for an optimizer that actually reordered
> > evaluations. Pretty strong evidence has already been presented that
> Clang
> > and GCC *don't* reorder expressions optimially. That they have a
> > consistent, fixed evaluation order.
> >
> > They just don't have the *same* order. As such, enforcing a specific
> order
> > will make nothing "HARDER".
>
> I think you missed the point. Bo is talking about *writing such an
> optimizer*.
>
> Right now, the logic such an optimizer would implement is:
>
> - For each possible non-default ordering X, is X more efficient?
>   - Yes ==> use ordering X
>   - No  ==> keep checking
> - No more possible orderings ==> use default ordering
>
> Granted, the first step may be complicated. But consider the logic that
> would be necessary under the proposal:
>
> - For each possible non-default ordering X, is X more efficient?
>   - Yes ==>
>     - Is the result from ordering X equivalent to
>       the standard mandated ordering under as-if?
>       - Yes ==> use ordering X
>       - No  ==> keep checking
>   - No  ==> keep checking
> - No more possible orderings ==> use standard mandated ordering
>
> (I've simplified; you wouldn't just use the first "better" order, you'd
> use the "best", but you get the idea.)
>
> The difference is the second check, which is *also* likely to be
> complicated. Bo's point is that writing the second check, which is
> necessary under the proposal to *ever* provide the optimization we're
> discussing, might be more complicated than writing a sanitizer to warn
> if you might be relying on a particular ordering. (This also ignores
> that the proposal might also preclude choosing orders that would
> otherwise be better choices.)
>
> So... no. "Enforcing" (i.e. enforced but with the as-if exception) a
> particular order *will* make something harder.
>

No, it will only make it harder if, *and only if*, this case is something
they start optimizing. If they never optimize this case, then it makes
nothing hard, since they're not trying to do it.

You're talking about not removing a language pain point simply because of a
possibility that may never come to pass.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Wednesday, December 30, 2015 at 2:55:55 PM UTC-5, Matthew Woehlke wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-30 14:09, Nicol Bol=
as wrote:
<br>&gt; On Wednesday, December 30, 2015 at 5:06:09 AM UTC-5, Bo Persson wr=
ote:
<br>&gt;&gt; I don&#39;t see this as a clear win. By specifying the order o=
f evaluation,=20
<br>&gt;&gt; you have added a limitation for the optimizer. Writing it now =
has become=20
<br>&gt;&gt; HARDER, not easier.=20
<br>&gt;=20
<br>&gt; That would only be true for an optimizer that actually reordered=
=20
<br>&gt; evaluations. Pretty strong evidence has already been presented tha=
t Clang=20
<br>&gt; and GCC *don&#39;t* reorder expressions optimially. That they have=
 a=20
<br>&gt; consistent, fixed evaluation order.
<br>&gt;=20
<br>&gt; They just don&#39;t have the *same* order. As such, enforcing a sp=
ecific order=20
<br>&gt; will make nothing &quot;HARDER&quot;.
<br>
<br>I think you missed the point. Bo is talking about *writing such an
<br>optimizer*.
<br>
<br>Right now, the logic such an optimizer would implement is:
<br>
<br>- For each possible non-default ordering X, is X more efficient?
<br>=C2=A0 - Yes =3D=3D&gt; use ordering X
<br>=C2=A0 - No =C2=A0=3D=3D&gt; keep checking
<br>- No more possible orderings =3D=3D&gt; use default ordering
<br>
<br>Granted, the first step may be complicated. But consider the logic that
<br>would be necessary under the proposal:
<br>
<br>- For each possible non-default ordering X, is X more efficient?
<br>=C2=A0 - Yes =3D=3D&gt;
<br>=C2=A0 =C2=A0 - Is the result from ordering X equivalent to
<br>=C2=A0 =C2=A0 =C2=A0 the standard mandated ordering under as-if?
<br>=C2=A0 =C2=A0 =C2=A0 - Yes =3D=3D&gt; use ordering X
<br>=C2=A0 =C2=A0 =C2=A0 - No =C2=A0=3D=3D&gt; keep checking
<br>=C2=A0 - No =C2=A0=3D=3D&gt; keep checking
<br>- No more possible orderings =3D=3D&gt; use standard mandated ordering
<br>
<br>(I&#39;ve simplified; you wouldn&#39;t just use the first &quot;better&=
quot; order, you&#39;d
<br>use the &quot;best&quot;, but you get the idea.)
<br>
<br>The difference is the second check, which is *also* likely to be
<br>complicated. Bo&#39;s point is that writing the second check, which is
<br>necessary under the proposal to *ever* provide the optimization we&#39;=
re
<br>discussing, might be more complicated than writing a sanitizer to warn
<br>if you might be relying on a particular ordering. (This also ignores
<br>that the proposal might also preclude choosing orders that would
<br>otherwise be better choices.)
<br>
<br>So... no. &quot;Enforcing&quot; (i.e. enforced but with the as-if excep=
tion) a
<br>particular order *will* make something harder.
<br></blockquote><div><br>No, it will only make it harder if, <i>and only i=
f</i>, this case is something they start optimizing. If they never optimize=
 this case, then it makes nothing hard, since they&#39;re not trying to do =
it.<br><br>You&#39;re talking about not removing a language pain point simp=
ly because of a possibility that may never come to pass.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_5164_1598572159.1451527483882--
------=_Part_5163_1882241431.1451527483882--

.

On Wed, Dec 30, 2015 at 1:15 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> ... what? I hope you don't genuinely believe that.
>
> And I'm not talking about some pedantic issue like using `malloc` or
> whatever. Memory safety can be broken simply by someone storing a
> pointer/reference to heap-allocated memory which is later deleted by your
> "memory safe" smart pointers.

If you mean "stack-allocated memory" that is true, but I
think the context is memory safety issue caused by OOE.

>> No choice has been defined as "right" yet.
>
>
> Well, if the last 20-odd years of C++ have taught us anything, it's that
> "undefined" is the wrong answer. Any order that ca be relied on
> cross-compiler is better than none.

"better" is a term lacking connection with "right".  One is relative,
to many latitudes, another is not.

>> Different people have different opinions.  For example,
>> she also considers iostream as "easy to learn" :(
>
>
> iostreams are easy to learn.
>
> They're just painful to actually use for anything, make writing new
> streambufs exceedingly arcane, and have needlessly-terrible performance. But
> they're quite easy to learn.

So you just supported my claim "different people have different
opinions".

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5974_87378185.1451593731074
Content-Type: multipart/alternative;
 boundary="----=_Part_5975_2043916853.1451593731075"

------=_Part_5975_2043916853.1451593731075
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 30, 2015 at 9:50:46 PM UTC-5, Zhihao Yuan wrote:
>
> On Wed, Dec 30, 2015 at 1:15 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > ... what? I hope you don't genuinely believe that.
> >
> > And I'm not talking about some pedantic issue like using `malloc` or
> > whatever. Memory safety can be broken simply by someone storing a
> > pointer/reference to heap-allocated memory which is later deleted by
> your
> > "memory safe" smart pointers.
>
> If you mean "stack-allocated memory" that is true, but I
> think the context is memory safety issue caused by OOE.
>

There are plenty of instances of problems even without naked new,
which is why there is need for an analyzer, and a method for
identification of owning vs non-owning pointers.

I was also being a bit more loose with the quote, referring more
to the spirit of there being a safe subset of C++, with type/memory
safety being an example of things that are unsafe.  That safe subset
does not contain "unsequenced calls to functions with side effects".
Eliminating places where you can find "unsequenced calls to functions
with side effects" thus expands this safe subset.  We've seen that it is
hard for experts, let alone most users, to identify these places.


> >> No choice has been defined as "right" yet.
>

I wasn't referring to "users making the right choice", but to "users being
able to recognize that there is undefined behavior" when I said "get it
right".


> > Well, if the last 20-odd years of C++ have taught us anything, it's that
> > "undefined" is the wrong answer. Any order that ca be relied on
> > cross-compiler is better than none.
>
> "better" is a term lacking connection with "right".  One is relative,
> to many latitudes, another is not.
>

Perfect is the enemy of good.  We don't necessarily need "right", but
we do need "better".  So, what's your better answer?  So far, the only
answers I've seen have been "Do nothing, teach users to recognize the
problem and avoid it, so that someone some day can optimize this case
and we'll get better performance" and "Specify a particular order where
previously there was no required order, as we've found that no one is
taking advantage of the relaxed order, and it just causes problems for
everyone".

So you just supported my claim "different people have different
> opinions".
>

Well, yes, that would be part of the definition of opinions, would it not?
I'm not sure what that has to do with people thinking that learning C++
is hard.  Are you saying that you don't think this piece is hard to learn?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Wednesday, December 30, 2015 at 9:50:46 PM UTC-5, Zhiha=
o Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Dec 30, 2=
015 at 1:15 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"1ylpsRixEQAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;java=
script:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; ... what? I hope you don&#39;t genuinely believe that.
<br>&gt;
<br>&gt; And I&#39;m not talking about some pedantic issue like using `mall=
oc` or
<br>&gt; whatever. Memory safety can be broken simply by someone storing a
<br>&gt; pointer/reference to heap-allocated memory which is later deleted =
by your
<br>&gt; &quot;memory safe&quot; smart pointers.
<br>
<br>If you mean &quot;stack-allocated memory&quot; that is true, but I
<br>think the context is memory safety issue caused by OOE.
<br></blockquote><div><br></div><div>There are plenty of instances of probl=
ems even without naked new,</div><div>which is why there is need for an ana=
lyzer, and a method for</div><div>identification of owning vs non-owning po=
inters.</div><div><br></div><div>I was also being a bit more loose with the=
 quote, referring more</div><div>to the spirit of there being a safe subset=
 of C++, with type/memory</div><div>safety being an example of things that =
are unsafe. =C2=A0That safe subset</div><div>does not contain &quot;unseque=
nced calls to functions with side effects&quot;.</div><div>Eliminating plac=
es where you can find &quot;unsequenced calls to functions</div><div>with s=
ide effects&quot; thus expands this safe subset. =C2=A0We&#39;ve seen that =
it is</div><div>hard for experts, let alone most users, to identify these p=
laces.</div><div>=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;">&=
gt;&gt; No choice has been defined as &quot;right&quot; yet.
<br></blockquote><div><br></div><div>I wasn&#39;t referring to &quot;users =
making the right choice&quot;, but to &quot;users being<br></div><div>able =
to recognize that there is undefined behavior&quot; when I said &quot;get i=
t right&quot;.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;">&gt; Well, if the last 20-odd years of C++ have taught us anything, =
it&#39;s that
<br>&gt; &quot;undefined&quot; is the wrong answer. Any order that ca be re=
lied on
<br>&gt; cross-compiler is better than none.
<br>
<br>&quot;better&quot; is a term lacking connection with &quot;right&quot;.=
 =C2=A0One is relative,
<br>to many latitudes, another is not.
<br></blockquote><div><br></div><div>Perfect is the enemy of good. =C2=A0We=
 don&#39;t necessarily need &quot;right&quot;, but</div><div>we do need &qu=
ot;better&quot;. =C2=A0So, what&#39;s your better answer? =C2=A0So far, the=
 only</div><div>answers I&#39;ve seen have been &quot;Do nothing, teach use=
rs to recognize the</div><div>problem and avoid it, so that someone some da=
y can optimize this case</div><div>and we&#39;ll get better performance&quo=
t; and &quot;Specify a particular order where</div><div>previously there wa=
s no required order, as we&#39;ve found that no one is</div><div>taking adv=
antage of the relaxed order, and it just causes problems for</div><div>ever=
yone&quot;.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">So you just supported my claim &quot;different people have different
<br>opinions&quot;.
<br></blockquote><div><br></div><div>Well, yes, that would be part of the d=
efinition of opinions, would it not?</div><div>I&#39;m not sure what that h=
as to do with people thinking that learning C++</div><div>is hard. =C2=A0Ar=
e you saying that you don&#39;t think this piece is hard to learn?</div><di=
v><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_5975_2043916853.1451593731075--
------=_Part_5974_87378185.1451593731074--

.

On Thu, Dec 31, 2015 at 2:28 PM, Greg Marr <gregmmarr@gmail.com> wrote:
> That safe subset
> does not contain "unsequenced calls to functions with side effects".
> Eliminating places where you can find "unsequenced calls to functions
> with side effects" thus expands this safe subset.  We've seen that it is
> hard for experts, let alone most users, to identify these places.
>
> [...]
>
> Perfect is the enemy of good.  We don't necessarily need "right", but
> we do need "better".  So, what's your better answer?  So far, the only
> answers I've seen have been "Do nothing, teach users to recognize the
> problem and avoid it, so that someone some day can optimize this case
> and we'll get better performance" and "Specify a particular order where
> previously there was no required order, as we've found that no one is
> taking advantage of the relaxed order, and it just causes problems for
> everyone".

I didn't talk about optimization.  If you view my other posts in
this thread, all I was pointing is that the sample pieces of code are
awful code, thus I don't see a point to make the code work in
some other way, no matter which way, by tweaking the language.

>> So you just supported my claim "different people have different
>> opinions".
>
> Well, yes, that would be part of the definition of opinions, would it not?
> I'm not sure what that has to do with people thinking that learning C++
> is hard.  Are you saying that you don't think this piece is hard to learn?

I think OOE is fairly easy to learn; the rule is just one sentence.
And I find it's fairly easy to follow -- just keep an eye on the functions
with dual-purpose in my code, which is what I should do.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5865_499212479.1451744319799
Content-Type: multipart/alternative;
 boundary="----=_Part_5866_1539736839.1451744319799"

------=_Part_5866_1539736839.1451744319799
Content-Type: text/plain; charset=UTF-8

On Thursday, December 31, 2015 at 4:27:46 PM UTC-5, Zhihao Yuan wrote:
>
> On Thu, Dec 31, 2015 at 2:28 PM, Greg Marr <greg...@gmail.com
> <javascript:>> wrote:
> > That safe subset
> > does not contain "unsequenced calls to functions with side effects".
> > Eliminating places where you can find "unsequenced calls to functions
> > with side effects" thus expands this safe subset.  We've seen that it is
> > hard for experts, let alone most users, to identify these places.
> >
> > [...]
> >
> > Perfect is the enemy of good.  We don't necessarily need "right", but
> > we do need "better".  So, what's your better answer?  So far, the only
> > answers I've seen have been "Do nothing, teach users to recognize the
> > problem and avoid it, so that someone some day can optimize this case
> > and we'll get better performance" and "Specify a particular order where
> > previously there was no required order, as we've found that no one is
> > taking advantage of the relaxed order, and it just causes problems for
> > everyone".
>
> I didn't talk about optimization.  If you view my other posts in
> this thread, all I was pointing is that the sample pieces of code are
> awful code, thus I don't see a point to make the code work in
> some other way, no matter which way, by tweaking the language.
>

Has calling code "awful" *ever* stopped it from being written?

Sure, most examples are torturous. But quite a few of them are *real*,
based on actual shipping code in actual products. So however "awful" it may
be, that code keeps getting written.

Telling programmers not to do it is not a viable solution, as proven by the
last 20 years of C++.

>> So you just supported my claim "different people have different
> >> opinions".
> >
> > Well, yes, that would be part of the definition of opinions, would it
> not?
> > I'm not sure what that has to do with people thinking that learning C++
> > is hard.  Are you saying that you don't think this piece is hard to
> learn?
>
> I think OOE is fairly easy to learn; the rule is just one sentence.
> And I find it's fairly easy to follow -- just keep an eye on the functions
> with dual-purpose in my code, which is what I should do.
>

Oh, it's easy to *say* those things. Yes, the rule is trivial.

But are you going to remember to "keep an eye on the functions" when it's
5AM and you need to get a shipping product out the door by 7AM? Bugs don't
necessarily happen because of ignorance; people *know* the rule. These bugs
happen because of how easy it is to break it without realizing that it's
been broken. They happen because human beings make mistakes.

After all, you could apply your same logic to smart pointers. "I think
deletion is fairly easy to learn; the rule is just one sentence. And I find
it's fairly easy to follow -- just keep an eye on allocated pointers in my
code, which is what I should do."

And yet, we still invented smart pointers. We encourage their use and
discourage the use of naked `new` and `delete`. Why? Because it creates
significantly safer code, while having a minimal impact on performance. It
makes it so than an entire class of mistakes become impossible (allocations
owned by the stack not being destroyed under stack unwinding), while
significantly reducing another (general memory ownership issues).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Thursday, December 31, 2015 at 4:27:46 PM UTC-5, Zhihao Yuan wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On Thu, Dec 31, 2015 at 2:28 PM, Gr=
eg Marr &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"DlgYMA3uEQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">greg...@gmail.com</a>&gt; wrote:
<br>&gt; That safe subset
<br>&gt; does not contain &quot;unsequenced calls to functions with side ef=
fects&quot;.
<br>&gt; Eliminating places where you can find &quot;unsequenced calls to f=
unctions
<br>&gt; with side effects&quot; thus expands this safe subset. =C2=A0We&#3=
9;ve seen that it is
<br>&gt; hard for experts, let alone most users, to identify these places.
<br>&gt;
<br>&gt; [...]
<br>&gt;
<br>&gt; Perfect is the enemy of good. =C2=A0We don&#39;t necessarily need =
&quot;right&quot;, but
<br>&gt; we do need &quot;better&quot;. =C2=A0So, what&#39;s your better an=
swer? =C2=A0So far, the only
<br>&gt; answers I&#39;ve seen have been &quot;Do nothing, teach users to r=
ecognize the
<br>&gt; problem and avoid it, so that someone some day can optimize this c=
ase
<br>&gt; and we&#39;ll get better performance&quot; and &quot;Specify a par=
ticular order where
<br>&gt; previously there was no required order, as we&#39;ve found that no=
 one is
<br>&gt; taking advantage of the relaxed order, and it just causes problems=
 for
<br>&gt; everyone&quot;.
<br>
<br>I didn&#39;t talk about optimization. =C2=A0If you view my other posts =
in
<br>this thread, all I was pointing is that the sample pieces of code are
<br>awful code, thus I don&#39;t see a point to make the code work in
<br>some other way, no matter which way, by tweaking the language.<br></blo=
ckquote><div><br>Has calling code &quot;awful&quot; <i>ever</i> stopped it =
from being written?<br><br>Sure, most examples are torturous. But quite a f=
ew of them are <i>real</i>, based on actual shipping code in actual product=
s. So however &quot;awful&quot; it may be, that code keeps getting written.=
<br><br>Telling programmers not to do it is not a viable solution, as prove=
n by the last 20 years of C++.<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;">
&gt;&gt; So you just supported my claim &quot;different people have differe=
nt
<br>&gt;&gt; opinions&quot;.
<br>&gt;
<br>&gt; Well, yes, that would be part of the definition of opinions, would=
 it not?
<br>&gt; I&#39;m not sure what that has to do with people thinking that lea=
rning C++
<br>&gt; is hard. =C2=A0Are you saying that you don&#39;t think this piece =
is hard to learn?
<br>
<br>I think OOE is fairly easy to learn; the rule is just one sentence.
<br>And I find it&#39;s fairly easy to follow -- just keep an eye on the fu=
nctions
<br>with dual-purpose in my code, which is what I should do.
<br></blockquote><div><br>Oh, it&#39;s easy to <i>say</i> those things. Yes=
, the rule is trivial.<br><br>But are you going to remember to &quot;keep a=
n eye on the functions&quot; when it&#39;s 5AM and you need to get a shippi=
ng product out the door by 7AM? Bugs don&#39;t necessarily happen because o=
f ignorance; people <i>know</i> the rule. These bugs happen because of how =
easy it is to break it without realizing that it&#39;s been broken. They ha=
ppen because human beings make mistakes.<br><br>After all, you could apply =
your same logic to smart pointers. &quot;I think deletion is fairly easy to=
 learn; the rule is just one sentence. And I find it&#39;s fairly easy to f=
ollow -- just keep an eye on allocated pointers in my code, which is what I=
 should do.&quot;<br><br>And yet, we still invented smart pointers. We enco=
urage their use and discourage the use of naked `new` and `delete`. Why? Be=
cause it creates significantly safer code, while having a minimal impact on=
 performance. It makes it so than an entire class of mistakes become imposs=
ible (allocations owned by the stack not being destroyed under stack unwind=
ing), while significantly reducing another (general memory ownership issues=
).<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_5866_1539736839.1451744319799--
------=_Part_5865_499212479.1451744319799--

.

On Sat, Jan 2, 2016 at 8:18 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> After all, you could apply your same logic to smart pointers. "I think
> deletion is fairly easy to learn; the rule is just one sentence. And I find
> it's fairly easy to follow -- just keep an eye on allocated pointers in my
> code, which is what I should do."

Chapter 3.7, 3.8, and 5.3.5 are not "one sentence", and it's very hard
to follow, because owning raw pointers are typical types with non-local
effect, where you cannot "keep an eye on" -- you need multiple eyes,
deep into 3rd party libraries.

But OOE is a thing can be resolved locally, one eye is enough.

> And yet, we still invented smart pointers. We encourage their use and
> discourage the use of naked `new` and `delete`. Why? Because it creates
> significantly safer code, while having a minimal impact on performance. It
> makes it so than an entire class of mistakes become impossible (allocations
> owned by the stack not being destroyed under stack unwinding), while
> significantly reducing another (general memory ownership issues).

I don't describe smart pointers as "safer".  Smart pointers just
allow me to put more logic in the code.

But I found that a dedicated OOE encourages people to put less
logic in the code.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_142_196912410.1451798051733
Content-Type: multipart/alternative;
 boundary="----=_Part_143_1729086317.1451798051733"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8B=E5=8D=881:58:11=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tuesday, December 29, 2015 at 4:05:34 PM UTC-5, Matthew Woehlke wrote:
>>
>> On 2015-12-29 15:17, Arthur O'Dwyer wrote:=20
>> > And the best part of this whole proposal is that there's *no tradeoff*=
..=20
>> We=20
>> > don't need to pessimize any existing code to get these benefits.=20
>>
>> Except we're doing *exactly that*. We're saying that existing code that=
=20
>> is correct regardless of order of execution must now be evaluated in a=
=20
>> specific order, even if that order is less efficient than the optimal=20
>> order, or even existing order.=20
>
> =20
>
> Is the cost of actual or potential lost performance of existing code,=20
>> plus the burden of having to spell out order of evaluation (e.g. by use=
=20
>> of additional temporaries) where it is known to matter, worth the=20
>> benefit of not accidentally writing bad code?=20
>>
>
> Yes, yes, a thousand times yes!
>
> The theoretical potential lost cost of ANY potential optimization is wort=
h
> the price of avoiding incorrect behavior, especially when that optimizati=
on
> is not something that anyone is doing, so there is no actual cost for
> existing correct code.  As shown in this thread, two of the major compile=
rs
> choose opposite orders, so unless you're writing only to one compiler, yo=
u
> are already getting the non-optimal order, if there is such a thing.
>
> You already have to use temporaries for where order of execution does
> matter, as there is no other way to define the order of execution.
> This doesn't change that in the least.  The only way to avoid the=20
> temporaries
> where it matters is to specify the order of evaluation.
>
> Temporaries? Not always. It depends on the type of the argument and the=
=20
parameter.

See also P0135R0.

Then the remained problem is how to figure out the name of the new variable=
..

I am reminded of some CppCon talks from this year and last year.
>
> CppCon 2015, Herb Sutter
> "Writing Good C++14... By Default"
>
> The goal is that "C++ Code compiled in the safe subset is never the
> root cause of type/memory safety errors, except where explicitly annotate=
d
> as unsafe".
>
> Writing a function with multiple parameters should be part of that safe=
=20
> subset.
> We shouldn't have to create temporaries and make our code harder to read
> just to make the code safe, and get the types of those temporaries right =
so
> that we don't have unnecessary copies, or then deal with dangling=20
> references.
>
>
> CppCon 2014, Herb Sutter, final session
> "Back to the Basics! Essentials of Modern C++ Style"
>
> "Hi, my name is Herb.  ...  Today I want to talk about the importance of=
=20
> resisting complexity.  ...  People that are under the influence of=20
> complexity
> often think that they're thinking more lucidly ... we get so used to=20
> complexity ... once you know a lot about anything, including C++, it's=20
> really
> hard to forget that you're an expert.  ...  We need to give good guidance=
=20
> to
> the big circle."
>
> There are roughly 3 million professional C++ developers out there.
> If we experts can't even get this right, how are they expected to do so?
>
>
> The right thing is to stop anyone who write such code. This is true=20
whether the proposal is adopted or not.=20


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=89 UTC+8=E4=B8=8B=E5=8D=881:58:11=EF=BC=8CGreg Marr=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;">On Tuesday, December =
29, 2015 at 4:05:34 PM UTC-5, Matthew Woehlke wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">On 2015-12-29 15:17, Arthur O&#39;Dwyer wrote:
<br>&gt; And the best part of this whole proposal is that there&#39;s *no t=
radeoff*. We
<br>&gt; don&#39;t need to pessimize any existing code to get these benefit=
s.
<br>
<br>Except we&#39;re doing *exactly that*. We&#39;re saying that existing c=
ode that
<br>is correct regardless of order of execution must now be evaluated in a
<br>specific order, even if that order is less efficient than the optimal
<br>order, or even existing order.=C2=A0</blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">=C2=A0</blockquote><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">Is the cost of actual or potential lost performance of existing code,
<br>plus the burden of having to spell out order of evaluation (e.g. by use
<br>of additional temporaries) where it is known to matter, worth the
<br>benefit of not accidentally writing bad code?
<br></blockquote><div><br></div><div><div>Yes, yes, a thousand times yes!</=
div><div><br></div><div>The theoretical potential lost cost of ANY potentia=
l optimization is worth</div><div>the price of avoiding incorrect behavior,=
 especially when that optimization</div><div>is not something that anyone i=
s doing, so there is no actual cost for</div><div>existing correct code. =
=C2=A0As shown in this thread, two of the major compilers</div><div>choose =
opposite orders, so unless you&#39;re writing only to one compiler, you</di=
v><div>are already getting the non-optimal order, if there is such a thing.=
</div><div><br></div><div>You already have to use temporaries for where ord=
er of execution does</div><div>matter, as there is no other way to define t=
he order of execution.</div><div>This doesn&#39;t change that in the least.=
 =C2=A0The only way to avoid the temporaries</div><div>where it matters is =
to specify the order of evaluation.</div><div><br></div></div></blockquote>=
<div>Temporaries? Not always. It depends on the type of the argument and th=
e parameter.<br><br>See also P0135R0.<br><br>Then the remained problem is h=
ow to figure out the name of the new variable.<br><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><div></div><div>I am reminded of some Cp=
pCon talks from this year and last year.</div><div><br></div><div>CppCon 20=
15, Herb Sutter</div><div>&quot;Writing Good C++14... By Default&quot;</div=
><div><br></div><div>The goal is that &quot;C++ Code compiled in the safe s=
ubset is never the</div><div>root cause of type/memory safety errors, excep=
t where explicitly annotated</div><div>as unsafe&quot;.</div><div><br></div=
><div>Writing a function with multiple parameters should be part of that sa=
fe subset.</div><div>We shouldn&#39;t have to create temporaries and make o=
ur code harder to read</div><div>just to make the code safe, and get the ty=
pes of those temporaries right so</div><div>that we don&#39;t have unnecess=
ary copies, or then deal with dangling references.</div><div><br></div><div=
><br></div><div>CppCon 2014, Herb Sutter, final session</div><div>&quot;Bac=
k to the Basics! Essentials of Modern C++ Style&quot;</div><div><br></div><=
div>&quot;Hi, my name is Herb. =C2=A0... =C2=A0Today I want to talk about t=
he importance of=C2=A0</div><div>resisting complexity. =C2=A0... =C2=A0Peop=
le that are under the influence of complexity</div><div>often think that th=
ey&#39;re thinking more lucidly ... we get so used to=C2=A0</div><div>compl=
exity ... once you know a lot about anything, including C++, it&#39;s reall=
y</div><div>hard to forget that you&#39;re an expert. =C2=A0... =C2=A0We ne=
ed to give good guidance to</div><div>the big circle.&quot;</div><div><br><=
/div><div>There are roughly 3 million professional C++ developers out there=
..</div><div>If we experts can&#39;t even get this right, how are they expec=
ted to do so?</div><div><br></div><div><br></div></div></blockquote><div>Th=
e right thing is to stop anyone who write such code. This is true whether t=
he proposal is adopted or not. <br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_143_1729086317.1451798051733--
------=_Part_142_196912410.1451798051733--

.

------=_Part_10507_374803075.1451799342634
Content-Type: multipart/alternative;
 boundary="----=_Part_10508_530993041.1451799342634"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8A=E5=8D=884:17:46=EF=BC=8CArthur O'Dwyer=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke <mwoehlk...@gmail.com=20
> <javascript:>> wrote:
>
>> On 2015-12-24 21:08, Arthur O'Dwyer wrote:
>
> > - GCC 5.3 evaluates function arguments right-to-left, meaning that it=
=20
>> will
>>
> > "do the right thing" with your example but "do the wrong thing" (i.e.,
>> > spill) with a(external_function(), sqrt(x), pow(y,z)).
>> > - Clang 3.7 evaluates function arguments left-to-right, meaning that i=
t
>> > will "do the wrong thing" (i.e., spill) with your example but "do the=
=20
>> right
>> > thing" with a(external_function(), sqrt(x), pow(y,z)).
>>
>> Heh... room for improvement :-). But not possible if order of evaluation
>> becomes specified, which is why folks are being vocal about this.
>>
>> > - if you think you're getting optimizations like that today, under=20
>> today's
>> > rules, you're definitely wrong;
>>
>> ...which is sort of the point others were making... just because we're
>> not taking as much advantage of unspecified order *now* doesn't mean we
>> won't in the future. That is, if there is still unspecified order to be
>> leveraged for performance gains. IOW, we would be cutting off avenues
>> for future optimization.
>>
>
> I agree.
> However, like Nicol Bolas, I think that the huge productivity benefits of=
=20
> having a defined order of evaluation for function arguments (even better:=
=20
> for all expressions) will benefit humanity *vastly* more than this=20
> particular "avenue for future optimization."
>
> I mean, there are only a finite number of Clang developers, right? Which=
=20
> feature would you rather they spend time on: optimizations in general, or=
=20
> an evaluation-order sanitizer in particular? Because under the *current*=
=20
> state of affairs, we're basically telling them they *have* to write an=20
> evaluation-order sanitizer, just in order to detect and diagnose all the=
=20
> buggy non-portable code that our fellow software engineers are writing=20
> every day. If we could just nail down the evaluation order in the standar=
d,=20
> so that it became defined and portable, then that problem would completel=
y=20
> go away =E2=80=94 no Clang developer would have to spend a minute longer =
on that=20
> particular sanitizer =E2=80=94 and they could turn their efforts away fro=
m=20
> "cleaning up after C++'s messes" and back toward "writing neat codegen=20
> optimizations." ;)
>
> I don't think things would be different here, at least when C is still=20
supported. Someone should inform WG14 to make this proposal also effective=
=20
for ISO C before the proposal voted into ISO C++. After major C=20
implementations taking the revised standard in the default mode, Clang=20
developers are free to work in this way safely (enough).


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=89 UTC+8=E4=B8=8A=E5=8D=884:17:46=EF=BC=8CArthur O&#39;Dwyer=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">On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke <span dir=3D"ltr">&lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"AtOoIRJ=
NEQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">mwoe=
hlk...@gmail.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><=
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">On 2015-12-24 21:08, Arthur O&#39;Dwyer wrote:</blockquote>=
<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;p=
adding-left:1ex">&gt; - GCC 5.3 evaluates function arguments right-to-left,=
 meaning that it will<br></blockquote><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">
&gt; &quot;do the right thing&quot; with your example but &quot;do the wron=
g thing&quot; (i.e.,<br>
&gt; spill) with a(external_function(), sqrt(x), pow(y,z)).<br>
&gt; - Clang 3.7 evaluates function arguments left-to-right, meaning that i=
t<br>
&gt; will &quot;do the wrong thing&quot; (i.e., spill) with your example bu=
t &quot;do the right<br>
&gt; thing&quot; with a(external_function(), sqrt(x), pow(y,z)).<br>
<br>
Heh... room for improvement :-). But not possible if order of evaluation<br=
>
becomes specified, which is why folks are being vocal about this.<br>
<br>
&gt; - if you think you&#39;re getting optimizations like that today, under=
 today&#39;s<br>
&gt; rules, you&#39;re definitely wrong;<br>
<br>
....which is sort of the point others were making... just because we&#39;re<=
br>
not taking as much advantage of unspecified order *now* doesn&#39;t mean we=
<br>
won&#39;t in the future. That is, if there is still unspecified order to be=
<br>
leveraged for performance gains. IOW, we would be cutting off avenues<br>
for future optimization.<br></blockquote><div><br></div><div>I agree.</div>=
<div>However, like Nicol Bolas, I think that the huge productivity benefits=
 of having a defined order of evaluation for function arguments (even bette=
r: for all expressions) will benefit humanity <i>vastly</i> more than this =
particular &quot;avenue for future optimization.&quot;</div><div><br></div>=
<div>I mean, there are only a finite number of Clang developers, right? Whi=
ch feature would you rather they spend time on: optimizations in general, o=
r an evaluation-order sanitizer in particular? Because under the <i>current=
</i> state of affairs, we&#39;re basically telling them they <i>have</i> to=
 write an evaluation-order sanitizer, just in order to detect and diagnose =
all the buggy non-portable code that our fellow software engineers are writ=
ing every day. If we could just nail down the evaluation order in the stand=
ard, so that it became defined and portable, then that problem would comple=
tely go away =E2=80=94 no Clang developer would have to spend a minute long=
er on that particular sanitizer =E2=80=94 and they could turn their efforts=
 away from &quot;cleaning up after C++&#39;s messes&quot; and back toward &=
quot;writing neat codegen optimizations.&quot; ;)</div><div><br></div></div=
></div></div></blockquote><div>I don&#39;t think things would be different =
here, at least when C is still supported. Someone should inform WG14 to mak=
e this proposal also effective for ISO C before the proposal voted into ISO=
 C++. After major C implementations taking the revised standard in the defa=
ult mode, Clang developers are free to work in this way safely (enough).<br=
><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_10508_530993041.1451799342634--
------=_Part_10507_374803075.1451799342634--

.

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

Much code designated as "awful" is so because the language rules are
awful.  C and C++ decided that it would be good to have unary increment and
decrement operators, and having done so, completely dropped the ball on
making their use properly specified.  There is no reason, for example, to
consider a[++i] =3D i; to be awful except that the language doesn't define
its behavior.  It's no worse than while (*to++ =3D *from++); and that's a
construct found in the language bible.

On Sun, Jan 3, 2016 at 12:35 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:

>
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8A=E5=8D=884:17:46=EF=BC=8CArthur O'Dwyer=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>> On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke <mwoehlk...@gmail.com>
>> wrote:
>>
>>> On 2015-12-24 21:08, Arthur O'Dwyer wrote:
>>
>> > - GCC 5.3 evaluates function arguments right-to-left, meaning that it
>>> will
>>>
>> > "do the right thing" with your example but "do the wrong thing" (i.e.,
>>> > spill) with a(external_function(), sqrt(x), pow(y,z)).
>>> > - Clang 3.7 evaluates function arguments left-to-right, meaning that =
it
>>> > will "do the wrong thing" (i.e., spill) with your example but "do the
>>> right
>>> > thing" with a(external_function(), sqrt(x), pow(y,z)).
>>>
>>> Heh... room for improvement :-). But not possible if order of evaluatio=
n
>>> becomes specified, which is why folks are being vocal about this.
>>>
>>> > - if you think you're getting optimizations like that today, under
>>> today's
>>> > rules, you're definitely wrong;
>>>
>>> ...which is sort of the point others were making... just because we're
>>> not taking as much advantage of unspecified order *now* doesn't mean we
>>> won't in the future. That is, if there is still unspecified order to be
>>> leveraged for performance gains. IOW, we would be cutting off avenues
>>> for future optimization.
>>>
>>
>> I agree.
>> However, like Nicol Bolas, I think that the huge productivity benefits o=
f
>> having a defined order of evaluation for function arguments (even better=
:
>> for all expressions) will benefit humanity *vastly* more than this
>> particular "avenue for future optimization."
>>
>> I mean, there are only a finite number of Clang developers, right? Which
>> feature would you rather they spend time on: optimizations in general, o=
r
>> an evaluation-order sanitizer in particular? Because under the *current*
>> state of affairs, we're basically telling them they *have* to write an
>> evaluation-order sanitizer, just in order to detect and diagnose all the
>> buggy non-portable code that our fellow software engineers are writing
>> every day. If we could just nail down the evaluation order in the standa=
rd,
>> so that it became defined and portable, then that problem would complete=
ly
>> go away =E2=80=94 no Clang developer would have to spend a minute longer=
 on that
>> particular sanitizer =E2=80=94 and they could turn their efforts away fr=
om
>> "cleaning up after C++'s messes" and back toward "writing neat codegen
>> optimizations." ;)
>>
>> I don't think things would be different here, at least when C is still
> supported. Someone should inform WG14 to make this proposal also effectiv=
e
> for ISO C before the proposal voted into ISO C++. After major C
> implementations taking the revised standard in the default mode, Clang
> developers are free to work in this way safely (enough).
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">Much code designated as &quot;awful&quot; is so because th=
e language rules are awful.=C2=A0 C and C++ decided that it would be good t=
o have unary increment and decrement operators, and having done so, complet=
ely dropped the ball on making their use properly specified.=C2=A0 There is=
 no reason, for example, to consider <font face=3D"monospace, monospace">a[=
++i] =3D i;</font> to be awful except that the language doesn&#39;t define =
its behavior.=C2=A0 It&#39;s no worse than <font face=3D"monospace, monospa=
ce">while (*to++ =3D *from++);</font> and that&#39;s a construct found in t=
he language bible.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Sun, Jan 3, 2016 at 12:35 AM, FrankHB1989 <span dir=3D"ltr">&lt;<=
a href=3D"mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>=E5=9C=
=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=
=B8=8A=E5=8D=884:17:46=EF=BC=8CArthur O&#39;Dwyer=E5=86=99=E9=81=93=EF=BC=
=9A<span class=3D""><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=
">On Tue, Dec 29, 2015 at 9:00 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a=
 rel=3D"nofollow">mwoehlk...@gmail.com</a>&gt;</span> wrote:<br><div><div c=
lass=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);bord=
er-left-style:solid;padding-left:1ex">On 2015-12-24 21:08, Arthur O&#39;Dwy=
er wrote:</blockquote><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">&gt; - GCC 5.3 evaluates function ar=
guments right-to-left, meaning that it will<br></blockquote><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=
">
&gt; &quot;do the right thing&quot; with your example but &quot;do the wron=
g thing&quot; (i.e.,<br>
&gt; spill) with a(external_function(), sqrt(x), pow(y,z)).<br>
&gt; - Clang 3.7 evaluates function arguments left-to-right, meaning that i=
t<br>
&gt; will &quot;do the wrong thing&quot; (i.e., spill) with your example bu=
t &quot;do the right<br>
&gt; thing&quot; with a(external_function(), sqrt(x), pow(y,z)).<br>
<br>
Heh... room for improvement :-). But not possible if order of evaluation<br=
>
becomes specified, which is why folks are being vocal about this.<br>
<br>
&gt; - if you think you&#39;re getting optimizations like that today, under=
 today&#39;s<br>
&gt; rules, you&#39;re definitely wrong;<br>
<br>
....which is sort of the point others were making... just because we&#39;re<=
br>
not taking as much advantage of unspecified order *now* doesn&#39;t mean we=
<br>
won&#39;t in the future. That is, if there is still unspecified order to be=
<br>
leveraged for performance gains. IOW, we would be cutting off avenues<br>
for future optimization.<br></blockquote><div><br></div><div>I agree.</div>=
<div>However, like Nicol Bolas, I think that the huge productivity benefits=
 of having a defined order of evaluation for function arguments (even bette=
r: for all expressions) will benefit humanity <i>vastly</i> more than this =
particular &quot;avenue for future optimization.&quot;</div><div><br></div>=
<div>I mean, there are only a finite number of Clang developers, right? Whi=
ch feature would you rather they spend time on: optimizations in general, o=
r an evaluation-order sanitizer in particular? Because under the <i>current=
</i> state of affairs, we&#39;re basically telling them they <i>have</i> to=
 write an evaluation-order sanitizer, just in order to detect and diagnose =
all the buggy non-portable code that our fellow software engineers are writ=
ing every day. If we could just nail down the evaluation order in the stand=
ard, so that it became defined and portable, then that problem would comple=
tely go away =E2=80=94 no Clang developer would have to spend a minute long=
er on that particular sanitizer =E2=80=94 and they could turn their efforts=
 away from &quot;cleaning up after C++&#39;s messes&quot; and back toward &=
quot;writing neat codegen optimizations.&quot; ;)</div><div><br></div></div=
></div></div></blockquote></span><div>I don&#39;t think things would be dif=
ferent here, at least when C is still supported. Someone should inform WG14=
 to make this proposal also effective for ISO C before the proposal voted i=
nto ISO C++. After major C implementations taking the revised standard in t=
he default mode, Clang developers are free to work in this way safely (enou=
gh).<br><br><br></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1144082ccbf0330528851059--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">=E2=80=8E&gt;&nbsp;<span style=3D"line-height: initial;">Has ca=
lling code "awful"</span><span style=3D"line-height: initial;">&nbsp;</span=
><i style=3D"line-height: initial;">ever</i><span style=3D"line-height: ini=
tial;">&nbsp;</span><span style=3D"line-height: initial;">stopped it from b=
eing written?</span></div>&nbsp;<div><span style=3D"line-height: initial;">=
Yes.&nbsp;</span></div><div><span style=3D"line-height: initial;">Well, to =
call it awful means it was already written so in that sense, no. But in gen=
eral, Yes. Both stopped it from being repeated (programmers do learn) and=
=E2=80=8E stopped it from being checked in. Not all awful code is stopped, =
but some/lots. &nbsp;Things could be worse.&nbsp;</span></div><div><div><br=
><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slat=
e Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initia=
l; background-color: rgb(255, 255, 255);"><span style=3D"line-height: initi=
al;">&gt; Telling programmers not to do it is not a viable solution, as pro=
ven by the last 20 years of C++.</span></div><div style=3D"width: 100%; fon=
t-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif;=
 color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 2=
55, 255);"><span style=3D"line-height: initial;"><br></span></div><div styl=
e=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);"><span style=3D"line-height: initial;">We do=
n't have proof (of what solution is most viable/effective/etc) until we exp=
erience, or at least consider, the alternative(s). =E2=80=8EIf we define an=
 order _and_ stop discouraging order-dependent code, will things look bette=
r or worse? Will we get more order-dependent code? Is that OK? Will order-d=
ependent code lose its smell once order is defined? Why do java guidelines =
still suggest avoiding it? Is it only because they worry ex-C/C++ coders wi=
ll be confused?</span></div><div style=3D"width: 100%; font-size: initial; =
font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 7=
3, 125); text-align: initial; background-color: rgb(255, 255, 255);"><span =
style=3D"line-height: initial;"><br></span></div><div style=3D"width: 100%;=
 font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-se=
rif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(25=
5, 255, 255);"><span style=3D"line-height: initial;">And if C remains unord=
ered and/or C++ chooses a different order than java,C#,etc, will we still n=
eed to discourage its use? </span></div><div style=3D"width: 100%; font-siz=
e: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; colo=
r: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 2=
55);"><span style=3D"line-height: initial;"><br></span></div><div style=3D"=
width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);">Tony</div><div style=3D"width: 100%; font-size: =
initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: =
rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255)=
;"><span style=3D"line-height: initial;"><br></span></div><div style=3D"wid=
th: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif=
, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-colo=
r: rgb(255, 255, 255);"><span style=3D"line-height: initial;"><br></span></=
div>                                                                       =
                                                              <div style=3D=
"display:none"></div>                                                      =
        <div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro'=
, sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; bac=
kground-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&=
nbsp;portable&nbsp;Babbage&nbsp;Device</div>                               =
        <div style=3D"display:none"></div><div style=3D"font-size: initial;=
 text-align: initial; background-color: rgb(255, 255, 255);"><table width=
=3D"100%" style=3D"background-color:white; border-spacing:0px;">           =
                               <tbody><tr><td></td><td id=3D"_separatorInte=
rnal" rowspan=3D"2" style=3D"text-align: center; font-size: initial; backgr=
ound-color: rgb(255, 255, 255);">                                          =
                                                  <span id=3D"_bb10TempSepa=
ratorText" style=3D"background-color:white; color:#0073BC;font-size:smaller=
;font-family:&quot;Slate Pro&quot;">&nbsp; Original Message &nbsp;</span>  =
    </td></tr>                                                             =
                                                                           =
                       <tr> <td colspan=3D"2"><div style=3D"border:none;bor=
der-top:solid #0073BC 1.0pt;"></div>                                       =
                                              </td></tr></tbody></table></d=
iv>                                                                        =
                                                                   <table w=
idth=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody>=
<tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initial; bac=
kground-color: rgb(255, 255, 255);">                           <div style=
=3D"font-size: smaller;font-family:&quot;Tahoma&quot;,&quot;BB Alpha Sans&q=
uot;,&quot;Slate Pro&quot;,sans-serif,&quot;sans-serif&quot;;">  <div><b>Fr=
om: </b>Nicol Bolas</div><div><b>Sent: </b>Saturday, January 2, 2016 9:18 A=
M</div><div><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Rep=
ly To: </b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-prop=
osals] Re: About order of evaluation</div></div></td></tr></tbody></table><=
div style=3D"border-style: solid none none; border-top-color: rgb(186, 188,=
 209); border-top-width: 1pt; font-size: initial; text-align: initial; back=
ground-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalContent" s=
tyle=3D"">On Thursday, December 31, 2015 at 4:27:46 PM UTC-5, Zhihao Yuan w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Dec 31, 2015 at 2=
:28 PM, Greg Marr &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"DlgYMA3uEQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>greg...@gmail.com</a>&gt; wrote:
<br>&gt; That safe subset
<br>&gt; does not contain "unsequenced calls to functions with side effects=
".
<br>&gt; Eliminating places where you can find "unsequenced calls to functi=
ons
<br>&gt; with side effects" thus expands this safe subset. &nbsp;We've seen=
 that it is
<br>&gt; hard for experts, let alone most users, to identify these places.
<br>&gt;
<br>&gt; [...]
<br>&gt;
<br>&gt; Perfect is the enemy of good. &nbsp;We don't necessarily need "rig=
ht", but
<br>&gt; we do need "better". &nbsp;So, what's your better answer? &nbsp;So=
 far, the only
<br>&gt; answers I've seen have been "Do nothing, teach users to recognize =
the
<br>&gt; problem and avoid it, so that someone some day can optimize this c=
ase
<br>&gt; and we'll get better performance" and "Specify a particular order =
where
<br>&gt; previously there was no required order, as we've found that no one=
 is
<br>&gt; taking advantage of the relaxed order, and it just causes problems=
 for
<br>&gt; everyone".
<br>
<br>I didn't talk about optimization. &nbsp;If you view my other posts in
<br>this thread, all I was pointing is that the sample pieces of code are
<br>awful code, thus I don't see a point to make the code work in
<br>some other way, no matter which way, by tweaking the language.<br></blo=
ckquote><div><br>Has calling code "awful" <i>ever</i> stopped it from being=
 written?<br><br>Sure, most examples are torturous. But quite a few of them=
 are <i>real</i>, based on actual shipping code in actual products. So howe=
ver "awful" it may be, that code keeps getting written.<br><br>Telling prog=
rammers not to do it is not a viable solution, as proven by the last 20 yea=
rs of C++.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt;&gt; So you just supported my claim "different people have different
<br>&gt;&gt; opinions".
<br>&gt;
<br>&gt; Well, yes, that would be part of the definition of opinions, would=
 it not?
<br>&gt; I'm not sure what that has to do with people thinking that learnin=
g C++
<br>&gt; is hard. &nbsp;Are you saying that you don't think this piece is h=
ard to learn?
<br>
<br>I think OOE is fairly easy to learn; the rule is just one sentence.
<br>And I find it's fairly easy to follow -- just keep an eye on the functi=
ons
<br>with dual-purpose in my code, which is what I should do.
<br></blockquote><div><br>Oh, it's easy to <i>say</i> those things. Yes, th=
e rule is trivial.<br><br>But are you going to remember to "keep an eye on =
the functions" when it's 5AM and you need to get a shipping product out the=
 door by 7AM? Bugs don't necessarily happen because of ignorance; people <i=
>know</i> the rule. These bugs happen because of how easy it is to break it=
 without realizing that it's been broken. They happen because human beings =
make mistakes.<br><br>After all, you could apply your same logic to smart p=
ointers. "I think deletion is fairly easy to learn; the rule is just one se=
ntence. And I find it's fairly easy to follow -- just keep an eye on alloca=
ted pointers in my code, which is what I should do."<br><br>And yet, we sti=
ll invented smart pointers. We encourage their use and discourage the use o=
f naked `new` and `delete`. Why? Because it creates significantly safer cod=
e, while having a minimal impact on performance. It makes it so than an ent=
ire class of mistakes become impossible (allocations owned by the stack not=
 being destroyed under stack unwinding), while significantly reducing anoth=
er (general memory ownership issues).<br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
<br><!--end of _originalContent --></div></div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

.

------=_Part_13118_2063701225.1451941950064
Content-Type: multipart/alternative;
 boundary="----=_Part_13119_99023663.1451941950065"

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

On Sunday, January 3, 2016 at 12:14:11 AM UTC-5, FrankHB1989 wrote:
>
> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8B=E5=8D=881:58:11=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A
>>
>> On Tuesday, December 29, 2015 at 4:05:34 PM UTC-5, Matthew Woehlke wrote=
:
>>>
>>> Is the cost of actual or potential lost performance of existing code,=
=20
>>>
>> plus the burden of having to spell out order of evaluation (e.g. by use=
=20
>>> of additional temporaries) where it is known to matter, worth the=20
>>> benefit of not accidentally writing bad code?=20
>>>
>>
>> You already have to use temporaries for where order of execution does
>> matter, as there is no other way to define the order of execution.
>> This doesn't change that in the least.  The only way to avoid the=20
>> temporaries
>> where it matters is to specify the order of evaluation.
>>
> Temporaries? Not always. It depends on the type of the argument and the=
=20
> parameter.
>

I believe that Matthew meant not temporaries in the true language sense, bu=
t
local variables that are added by the author solely to disambiguate the=20
order
of operations.

There are roughly 3 million professional C++ developers out there.
>> If we experts can't even get this right, how are they expected to do so?
>>
> The right thing is to stop anyone who write such code. This is true=20
> whether the proposal is adopted or not.=20
>

Again, "get this right" here means "tell whether or not there is an=20
ambiguous order of operations".

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

On Sunday, January 3, 2016 at 12:14:11 AM UTC-5, FrankHB1989 wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">=E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=
=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=881:58:11=EF=BC=
=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">On Tuesday, December 29, 2015 at 4:05:34 PM UTC-5, Matthew Woehlke wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">Is the cost of actual or potentia=
l lost performance of existing code,=C2=A0<br></blockquote><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">plus the burden of having to spell out order of eva=
luation (e.g. by use
<br>of additional temporaries) where it is known to matter, worth the
<br>benefit of not accidentally writing bad code?
<br></blockquote><div><br></div><div><div>You already have to use temporari=
es for where order of execution does<br></div><div>matter, as there is no o=
ther way to define the order of execution.</div><div>This doesn&#39;t chang=
e that in the least. =C2=A0The only way to avoid the temporaries</div><div>=
where it matters is to specify the order of evaluation.</div></div></blockq=
uote><div>Temporaries? Not always. It depends on the type of the argument a=
nd the parameter.<br></div></blockquote><div><br></div><div>I believe that =
Matthew meant not temporaries in the true language sense, but</div><div>loc=
al variables that are added by the author solely to disambiguate the order<=
/div><div>of operations.</div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>There are rough=
ly 3 million professional C++ developers out there.<br></div><div>If we exp=
erts can&#39;t even get this right, how are they expected to do so?</div></=
blockquote><div>The right thing is to stop anyone who write such code. This=
 is true whether the proposal is adopted or not. <br></div></blockquote><di=
v><br></div><div>Again, &quot;get this right&quot; here means &quot;tell wh=
ether or not there is an ambiguous order of operations&quot;.</div><div><br=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_13119_99023663.1451941950065--
------=_Part_13118_2063701225.1451941950064--

.

On 2016-01-04 16:12, Greg Marr wrote:
> On Sunday, January 3, 2016 at 12:14:11 AM UTC-5, FrankHB1989 wrote:
>> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89=
 UTC+8=E4=B8=8B=E5=8D=881:58:11=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=
=9A
>>> On Tuesday, December 29, 2015 at 4:05:34 PM UTC-5, Matthew Woehlke wrot=
e:
>>>> Is the cost of actual or potential lost performance of existing code,=
=20
>>>> plus the burden of having to spell out order of evaluation (e.g. by us=
e=20
>>>> of additional temporaries) where it is known to matter, worth the=20
>>>> benefit of not accidentally writing bad code?=20
>>>
>>> You already have to use temporaries for where order of execution does
>>> matter, as there is no other way to define the order of execution.
>>> This doesn't change that in the least.  The only way to avoid the=20
>>> temporaries where it matters is to specify the order of evaluation.

You're talking about where it matters for *correctness*. I was talking
about where it matters for *performance*.

>> Temporaries? Not always. It depends on the type of the argument and the=
=20
>> parameter.
>=20
> I believe that Matthew meant not temporaries in the true language sense, =
but
> local variables that are added by the author solely to disambiguate the=
=20
> order of operations.

Right. ("Scratch variables" would have been better. Sorry for the
confusion.)

--=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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

------=_Part_8693_1069953988.1451942627644
Content-Type: multipart/alternative;
 boundary="----=_Part_8694_83263950.1451942627644"

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

On Monday, January 4, 2016 at 1:35:29 PM UTC-5, Tony V E wrote:
>
> =E2=80=8E> Has calling code "awful" *ever* stopped it from being written?
> =20
> Yes.=20
> Well, to call it awful means it was already written so in that sense, no.=
=20
> But in general, Yes. Both stopped it from being repeated (programmers do=
=20
> learn) and=E2=80=8E stopped it from being checked in. Not all awful code =
is=20
> stopped, but some/lots.  Things could be worse.=20
>

Exactly, "not all awful code is stopped".  This means that calling it awful
has not stopped it from being written.  It may have stopped some
authors from writing it in some situations, but it is still being written.
=20

> > Telling programmers not to do it is not a viable solution, as proven by=
=20
> the last 20 years of C++.
>
> We don't have proof (of what solution is most viable/effective/etc) until=
=20
> we experience, or at least consider, the alternative(s).
>

We've had more than 20 years of the alternative to providing an order.
What other alternatives have we not considered?
=20

> =E2=80=8EIf we define an order _and_ stop discouraging order-dependent co=
de
>

Then don't do that.  Just define the order, so it's the same across all
compilers, and still discourage writing it.  There are plenty of things tha=
t
are legal but discouraged, such as naked new and delete.
=20

> , will things look better or worse? Will we get more order-dependent code=
?=20
> Is that OK? Will order-dependent code lose its smell once order is define=
d?=20
> Why do java guidelines still suggest avoiding it? Is it only because they=
=20
> worry ex-C/C++ coders will be confused?
>

Have naked new and delete lost their smell? They're well defined.

Just because it's well defined doesn't mean that it's easy to understand.
Discourage writing it because it can be difficult to understand without
thorough study.

The current lack of order results in silent non-determinism.
Adding order makes it deterministic, so users don't have silent portability
issues when moving between compilers with different orders.
That eliminates one of the reasons for not writing it, but not the other(s)=
..

And if C remains unordered and/or C++ chooses a different order than=20
> java,C#,etc, will we still need to discourage its use?
>

Yes, still discourage its use while making it well defined.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

On Monday, January 4, 2016 at 1:35:29 PM UTC-5, Tony V E wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div lang=3D"en-US" style=3D"background-co=
lor:rgb(255,255,255);line-height:initial">                                 =
                                                     <div style=3D"width:10=
0%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,san=
s-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,25=
5,255)">=E2=80=8E&gt;=C2=A0<span style=3D"line-height:initial">Has calling =
code &quot;awful&quot;</span><span style=3D"line-height:initial">=C2=A0</sp=
an><i style=3D"line-height:initial">ever</i><span style=3D"line-height:init=
ial">=C2=A0</span><span style=3D"line-height:initial">stopped it from being=
 written?</span></div>=C2=A0<div><span style=3D"line-height:initial">Yes.=
=C2=A0</span></div><div><span style=3D"line-height:initial">Well, to call i=
t awful means it was already written so in that sense, no. But in general, =
Yes. Both stopped it from being repeated (programmers do learn) and=E2=80=
=8E stopped it from being checked in. Not all awful code is stopped, but so=
me/lots. =C2=A0Things could be worse.=C2=A0</span></div></div></blockquote>=
<div><br></div><div>Exactly, &quot;not all awful code is stopped&quot;. =C2=
=A0This means that calling it awful</div><div>has not stopped it from being=
 written. =C2=A0It may have stopped some</div><div>authors from writing it =
in some situations, but it is still being written.</div><div>=C2=A0</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 lang=3D"en-US" style=3D"bac=
kground-color:rgb(255,255,255);line-height:initial"><div><div><div style=3D=
"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-=
serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:r=
gb(255,255,255)"><span style=3D"line-height:initial">&gt; Telling programme=
rs not to do it is not a viable solution, as proven by the last 20 years of=
 C++.</span></div><div style=3D"width:100%;font-size:initial;font-family:Ca=
libri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-a=
lign:initial;background-color:rgb(255,255,255)"><span style=3D"line-height:=
initial"><br></span></div><div style=3D"width:100%;font-size:initial;font-f=
amily:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125=
);text-align:initial;background-color:rgb(255,255,255)"><span style=3D"line=
-height:initial">We don&#39;t have proof (of what solution is most viable/e=
ffective/etc) until we experience, or at least consider, the alternative(s)=
..</span></div></div></div></div></blockquote><div><br></div><div>We&#39;ve =
had more than 20 years of the alternative to providing an order.</div><div>=
What other alternatives have we not considered?</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div lang=3D"en-US" style=3D"backgr=
ound-color:rgb(255,255,255);line-height:initial"><div><div><div style=3D"wi=
dth:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-ser=
if,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(=
255,255,255)"><span style=3D"line-height:initial"> =E2=80=8EIf we define an=
 order _and_ stop discouraging order-dependent code</span></div></div></div=
></div></blockquote><div><br></div><div>Then don&#39;t do that. =C2=A0Just =
define the order, so it&#39;s the same across all</div><div>compilers, and =
still discourage writing it. =C2=A0There are plenty of things that</div><di=
v>are legal but discouraged, such as naked new and delete.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div lang=3D"en-US" styl=
e=3D"background-color:rgb(255,255,255);line-height:initial"><div><div><div =
style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#3=
9;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background=
-color:rgb(255,255,255)"><span style=3D"line-height:initial">, will things =
look better or worse? Will we get more order-dependent code? Is that OK? Wi=
ll order-dependent code lose its smell once order is defined? Why do java g=
uidelines still suggest avoiding it? Is it only because they worry ex-C/C++=
 coders will be confused?</span></div></div></div></div></blockquote><div><=
br></div><div>Have naked new and delete lost their smell? They&#39;re well =
defined.</div><div><br></div><div>Just because it&#39;s well defined doesn&=
#39;t mean that it&#39;s easy to understand.</div><div>Discourage writing i=
t because it can be difficult to understand without</div><div>thorough stud=
y.</div><div><br></div><div>The current lack of order results in silent non=
-determinism.</div><div>Adding order makes it deterministic, so users don&#=
39;t have silent portability</div><div>issues when moving between compilers=
 with different orders.</div><div>That eliminates one of the reasons for no=
t writing it, but not the other(s).</div><div><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 lang=3D"en-US" style=3D"background-color:r=
gb(255,255,255);line-height:initial"><div style=3D"width:100%;font-size:ini=
tial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rg=
b(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><span st=
yle=3D"line-height: initial; font-size: initial; text-align: initial;">And =
if C remains unordered and/or C++ chooses a different order than java,C#,et=
c, will we still need to discourage its use?</span></div></div></blockquote=
><div><br></div><div>Yes, still discourage its use while making it well def=
ined.</div><div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_8694_83263950.1451942627644--
------=_Part_8693_1069953988.1451942627644--

.

------=_Part_13360_883699993.1451942735507
Content-Type: multipart/alternative;
 boundary="----=_Part_13361_2003717345.1451942735507"

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

On Monday, January 4, 2016 at 4:19:43 PM UTC-5, Matthew Woehlke wrote:
>
> On 2016-01-04 16:12, Greg Marr wrote:=20
> > On Sunday, January 3, 2016 at 12:14:11 AM UTC-5, FrankHB1989 wrote:=20
> >> =E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=89 UTC+8=E4=B8=8B=E5=8D=881:58:11=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=
=BC=9A=20
> >>> On Tuesday, December 29, 2015 at 4:05:34 PM UTC-5, Matthew Woehlke=20
> wrote:=20
> >>>> Is the cost of actual or potential lost performance of existing code=
,=20
> >>>> plus the burden of having to spell out order of evaluation (e.g. by=
=20
> use=20
> >>>> of additional temporaries) where it is known to matter, worth the=20
> >>>> benefit of not accidentally writing bad code?=20
> >>>=20
> >>> You already have to use temporaries for where order of execution does=
=20
> >>> matter, as there is no other way to define the order of execution.=20
> >>> This doesn't change that in the least.  The only way to avoid the=20
> >>> temporaries where it matters is to specify the order of evaluation.=
=20
>
> You're talking about where it matters for *correctness*. I was talking=20
> about where it matters for *performance*.=20
>

What good is performance without correctness?  Don't you have to make
it work before you make it work fast?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

On Monday, January 4, 2016 at 4:19:43 PM UTC-5, Matthew Woehlke wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On 2016-01-04 16:12, Greg Marr wrot=
e:
<br>&gt; On Sunday, January 3, 2016 at 12:14:11 AM UTC-5, FrankHB1989 wrote=
:
<br>&gt;&gt; =E5=9C=A8 2015=E5=B9=B412=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=
=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=881:58:11=EF=BC=8CGreg Marr=E5=86=99=E9=
=81=93=EF=BC=9A
<br>&gt;&gt;&gt; On Tuesday, December 29, 2015 at 4:05:34 PM UTC-5, Matthew=
 Woehlke wrote:
<br>&gt;&gt;&gt;&gt; Is the cost of actual or potential lost performance of=
 existing code,=20
<br>&gt;&gt;&gt;&gt; plus the burden of having to spell out order of evalua=
tion (e.g. by use=20
<br>&gt;&gt;&gt;&gt; of additional temporaries) where it is known to matter=
, worth the=20
<br>&gt;&gt;&gt;&gt; benefit of not accidentally writing bad code?=20
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; You already have to use temporaries for where order of exe=
cution does
<br>&gt;&gt;&gt; matter, as there is no other way to define the order of ex=
ecution.
<br>&gt;&gt;&gt; This doesn&#39;t change that in the least. =C2=A0The only =
way to avoid the=20
<br>&gt;&gt;&gt; temporaries where it matters is to specify the order of ev=
aluation.
<br>
<br>You&#39;re talking about where it matters for *correctness*. I was talk=
ing
<br>about where it matters for *performance*.
<br></blockquote><div><br></div><div>What good is performance without corre=
ctness? =C2=A0Don&#39;t you have to make</div><div>it work before you make =
it work fast?</div><div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_13361_2003717345.1451942735507--
------=_Part_13360_883699993.1451942735507--

.

On 2016-01-04 16:25, Greg Marr wrote:
> What good is performance without correctness?  Don't you have to make
> it work before you make it work fast?

There's "correctness" and there's "correctness". Right now, there is
widespread discouragement against writing order-sensitive code in the
first place (in the sense of 'OOE will affect the result'). Thus, the
starting assumption is that the code "works", regardless of OOE.

The performance issue has to deal with whether the compiler can optimize
based on as-if (hard) or unspecified behavior (much easier).

Recall the original example (simplified for brevity) given way back:

  int n =3D layout()->nextPosition(m_pos) - m_pos;

The potential optimization here is to recognize 'm_pos' as a common
subexpression and to only load the value once. Under unspecified
ordering, the compiler is free to do exactly that. Under as-if, the
compiler must be able to "prove" that neither 'layout()' nor
'Layout::nextPosition(int)' can modify 'm_pos'. In realistic existing
code, this cannot be done, so an optimization opportunity is precluded.

However, as 'm_pos' is in fact is *not* modified, the correct behavior
is obtained in either case. Defined ordering therefore cost us an
optimization opportunity.

Going back to my original point, if it happened that 'm_pos' was, say, a
call to another, expensive function (not just a member variable load=C2=B9)=
,
and happened in a critical path such that the performance of the code is
significantly affected by whether or not CSE occurs, it would be
necessary to manually perform CSE by assigning the result to a local
scratch variable in order to obtain the optimization which defined order
would preclude.

Now, consider that future compilers might actually do better CSE or
related optimizations using unspecified order. While it's possible that
they'll touch a hot spot, they also have the potential to make minor
improvements over a *great many* places, which might produce a
noticeable overall improvement in a program, even though each individual
instance of optimization (which is all that we can reasonably expect
developers to do by hand) is negligible (and therefore, wouldn't be done
if it has to be done manually). That's on top of the potential for
manual CSE to be avoided due to having harmful effects on code clarity.

Or, to put it more succinctly, defined ordering severely restricts CSE
compared to the current situation.

(=C2=B9 or if the double load happens to result in poor cache behavior!)

--=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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

------=_Part_681_439138701.1451946682004
Content-Type: multipart/alternative;
 boundary="----=_Part_682_1785172939.1451946682004"

------=_Part_682_1785172939.1451946682004
Content-Type: text/plain; charset=UTF-8

On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:
>
> On 2016-01-04 16:25, Greg Marr wrote:
> > What good is performance without correctness?  Don't you have to make
> > it work before you make it work fast?
>
> There's "correctness" and there's "correctness". Right now, there is
> widespread discouragement against writing order-sensitive code in the
> first place (in the sense of 'OOE will affect the result'). Thus, the
> starting assumption is that the code "works", regardless of OOE.
>

I want to be sure I understand what you mean.  I see two possible
interpretations here:

1. Because of all the discouragement against writing order-sensitive
code, we should assume that all code that has ever been written
works regardless of OOE because everyone knows not to rely on it,
and can recognize and avoid all OOE errors.

2. The particular bit of code that is discussed next works regardless
of OOE because the author knows not to rely on it and has done
the necessary research to determine that the code is okay, so we're
going to assume for the purpose of this optimization discussion that
it is free of OOE errors.

The performance issue has to deal with whether the compiler can optimize
> based on as-if (hard) or unspecified behavior (much easier).
>

Or, to put it more succinctly, defined ordering severely restricts CSE
>
compared to the current situation.


I don't think anyone here disagrees with this.  The question is what do
most authors prefer, correctness or performance?  I don't know anyone
who would say "I'll take the wrong answer, just give it to me fast."

If optimizer writers want to make an option that says "assume that all
code has no OOE dependencies in it, and act as if the C++14 rules were
still in place" for those authors that write performance critical code where
they've already evaluated all of the OOE dependencies, I'd be fine with
that,
as long as the behavior wasn't unspecified by default.  This sounds like the
strict aliasing options in gcc/clang.

This is also like the difference between the fast and precise floating point
code options in the MS VC++ compiler.  There was a thread about possibly
changing that default recently, and overwhelmingly users preferred precise
over fast by default, with the option to change to fast where the author had
done the necessary analysis and testing to prove that there would be no
negative effects on correctness.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-01-04 16:2=
5, Greg Marr wrote:
<br>&gt; What good is performance without correctness? =C2=A0Don&#39;t you =
have to make
<br>&gt; it work before you make it work fast?
<br>
<br>There&#39;s &quot;correctness&quot; and there&#39;s &quot;correctness&q=
uot;. Right now, there is
<br>widespread discouragement against writing order-sensitive code in the
<br>first place (in the sense of &#39;OOE will affect the result&#39;). Thu=
s, the
<br>starting assumption is that the code &quot;works&quot;, regardless of O=
OE.
<br></blockquote><div><br></div><div>I want to be sure I understand what yo=
u mean. =C2=A0I see two possible</div><div>interpretations here:</div><div>=
<br></div><div>1. Because of all the discouragement against writing order-s=
ensitive</div><div>code, we should assume that all code that has ever been =
written=C2=A0</div><div>works regardless of OOE because everyone knows not =
to rely on it,</div><div>and can recognize and avoid all OOE errors.</div><=
div><br></div><div>2. The particular bit of code that is discussed next wor=
ks regardless</div><div>of OOE because the author knows not to rely on it a=
nd has done</div><div>the necessary research to determine that the code is =
okay, so we&#39;re</div><div>going to assume for the purpose of this optimi=
zation discussion that</div><div>it is free of OOE errors.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">The performance issue has =
to deal with whether the compiler can optimize
<br>based on as-if (hard) or unspecified behavior (much easier).
<br></blockquote><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">Or, to put it more succinctly, defined ordering severely restricts CSE=C2=
=A0<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">compared t=
o the current situation.=C2=A0</blockquote><div><br></div><div>I don&#39;t =
think anyone here disagrees with this. =C2=A0The question is what do</div><=
div>most authors prefer, correctness or performance? =C2=A0I don&#39;t know=
 anyone</div><div>who would say &quot;I&#39;ll take the wrong answer, just =
give it to me fast.&quot;</div><div><br></div><div>If optimizer writers wan=
t to make an option that says &quot;assume that all</div><div>code has no O=
OE dependencies in it, and act as if the C++14 rules were</div><div>still i=
n place&quot; for those authors that write performance critical code where<=
/div><div>they&#39;ve already evaluated all of the OOE dependencies, I&#39;=
d be fine with that,</div><div>as long as the behavior wasn&#39;t unspecifi=
ed by default. =C2=A0This sounds like the</div><div>strict aliasing options=
 in gcc/clang.</div><div><br></div><div>This is also like the difference be=
tween the fast and precise floating point</div><div>code options in the MS =
VC++ compiler. =C2=A0There was a thread about possibly</div><div>changing t=
hat default recently, and overwhelmingly users preferred precise</div><div>=
over fast by default, with the option to change to fast where the author ha=
d</div><div>done the necessary analysis and testing to prove that there wou=
ld be no</div><div>negative effects on correctness.</div><div><br></div></d=
iv>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_682_1785172939.1451946682004--
------=_Part_681_439138701.1451946682004--

.

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

On 4 January 2016 at 16:31, Greg Marr <gregmmarr@gmail.com> wrote:

> On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:
>>
>> On 2016-01-04 16:25, Greg Marr wrote:
>> > What good is performance without correctness?  Don't you have to make
>> > it work before you make it work fast?
>>
>> There's "correctness" and there's "correctness". Right now, there is
>> widespread discouragement against writing order-sensitive code in the
>> first place (in the sense of 'OOE will affect the result'). Thus, the
>> starting assumption is that the code "works", regardless of OOE.
>>
>
> I want to be sure I understand what you mean.  I see two possible
> interpretations here:
>
> 1. Because of all the discouragement against writing order-sensitive
> code, we should assume that all code that has ever been written
> works regardless of OOE because everyone knows not to rely on it,
> and can recognize and avoid all OOE errors.
>

If all you are going to do is bring up straw man arguments, then there is
no point in talking about this.

What the rest of us are talking about is inhibiting the compiler from
making correct non-order dependent code fast for the sake of codifying
currently broken code.  In the future, new order-dependent code will be
less broken because the order is fixed.

What is the impact of doing so?  I've yet to see anyone quantify it,
produce a reasonable benchmark, etc.

And there are downsides besides performance:

Fixing the order will definitely break code that is accidentally dependent
on the current order.  It doesn't magically make currently broken code
correct, unless you happen to pick the same order.

A compiler writer could not write a "parameter scrambler" to try and detect
order-dependent code, because that would no longer be a conforming C++
implementation.

A compiler writer could not write a sanitizer to detect order-dependent
code, because deliberate order-dependent code is indistinguishable from
accidental order-dependent code.

Heck, a conforming compiler couldn't refuse to compile order-dependent code
for the same reason.

If we nail down the order, there is effectively no way to discourage
writing order-dependent code.

We have a very similar situation with throwing through a noexcept(true)
function, as there is no way to distinguish between deliberately doing so
to terminate vs. accidentally doing so to terminate.

I think it is ridiculous to nail down the order and then tell people not to
rely on it.  When has that ever worked?

I don't think anyone here disagrees with this.  The question is what do
> most authors prefer, correctness or performance?  I don't know anyone
> who would say "I'll take the wrong answer, just give it to me fast."
>

I want the right answer, as fast as possible, w/o me having to write
convoluted / non-portable code because the compiler isn't allowed to
optimize my code.  I want unicorns, too. :-)


> If optimizer writers want to make an option that says "assume that all
> code has no OOE dependencies in it, and act as if the C++14 rules were
> still in place" for those authors that write performance critical code
> where
> they've already evaluated all of the OOE dependencies, I'd be fine with
> that,
> as long as the behavior wasn't unspecified by default.
>

That is beyond the purview of the standard.


> This sounds like the
> strict aliasing options in gcc/clang.
>

Which is beyond the purview of the standard.


> This is also like the difference between the fast and precise floating
> point
> code options in the MS VC++ compiler.  There was a thread about possibly
> changing that default recently, and overwhelmingly users preferred precise
> over fast by default, with the option to change to fast where the author
> had
> done the necessary analysis and testing to prove that there would be no
> negative effects on correctness.
>

I'm willing to bet that most people don't understand floating point well
enough to evaluate a decision like that; "precise" just sounds better than
"fast".  And that is also beyond the purview of the standard.


I'm not saying we shouldn't make this change, but we should do it based on
data and with our eyes open, instead of pretending one side is bright and
rosy while the other is satin's playground.
--
 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On 4 January 2016 at 16:31, Greg Marr <span dir=3D"ltr">&l=
t;<a href=3D"mailto:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@gmail.=
com</a>&gt;</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"><div dir=3D"ltr"><span class=3D"">On Monday, Janua=
ry 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke 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);border-left-style:solid;padding-left:1ex">On 2=
016-01-04 16:25, Greg Marr wrote:
<br>&gt; What good is performance without correctness?=C2=A0 Don&#39;t you =
have to make
<br>&gt; it work before you make it work fast?
<br>
<br>There&#39;s &quot;correctness&quot; and there&#39;s &quot;correctness&q=
uot;. Right now, there is
<br>widespread discouragement against writing order-sensitive code in the
<br>first place (in the sense of &#39;OOE will affect the result&#39;). Thu=
s, the
<br>starting assumption is that the code &quot;works&quot;, regardless of O=
OE.
<br></blockquote><div><br></div></span><div>I want to be sure I understand =
what you mean.=C2=A0 I see two possible</div><div>interpretations here:</di=
v><div><br></div><div>1. Because of all the discouragement against writing =
order-sensitive</div><div>code, we should assume that all code that has eve=
r been written=C2=A0</div><div>works regardless of OOE because everyone kno=
ws not to rely on it,</div><div>and can recognize and avoid all OOE errors.=
</div></div></blockquote><div><br></div><div>If all you are going to do is =
bring up straw man arguments, then there is no point in talking about this.=
</div><div><br></div><div>What the rest of us are talking about is inhibiti=
ng the compiler from making correct non-order dependent code fast for the s=
ake of codifying currently broken code.=C2=A0 In the future, new order-depe=
ndent code will be less broken because the order is fixed.</div><div><br></=
div><div>What is the impact of doing so?=C2=A0 I&#39;ve yet to see anyone q=
uantify it, produce a reasonable benchmark, etc.</div><div><br></div><div>A=
nd there are downsides besides performance:</div><div><br></div><div>Fixing=
 the order will definitely break code that is accidentally dependent on the=
 current order.=C2=A0 It doesn&#39;t magically make currently broken code c=
orrect, unless you happen to pick the same order.<br></div><div><br></div><=
div>A compiler writer could not write a &quot;parameter scrambler&quot; to =
try and detect order-dependent code, because that would no longer be a conf=
orming C++ implementation.</div><div><br></div><div>A compiler writer could=
 not write a sanitizer to detect order-dependent code, because deliberate o=
rder-dependent code is indistinguishable from accidental order-dependent co=
de.</div><div><br></div><div>Heck, a conforming compiler couldn&#39;t refus=
e to compile order-dependent code for the same reason.</div><div><br></div>=
<div>If we nail down the order, there is effectively no way to discourage w=
riting order-dependent code.</div><div><br></div><div>We have a very simila=
r situation with throwing through a noexcept(true) function, as there is no=
 way to distinguish between deliberately doing so to terminate vs. accident=
ally doing so to terminate.</div><div><br></div><div>I think it is ridiculo=
us to nail down the order and then tell people not to rely on it.=C2=A0 Whe=
n has that ever worked?<br></div><div><br></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>I don&#39;t think anyone here disagrees with this.=C2=A0 The =
question is what do<br></div><div>most authors prefer, correctness or perfo=
rmance?=C2=A0 I don&#39;t know anyone</div><div>who would say &quot;I&#39;l=
l take the wrong answer, just give it to me fast.&quot;</div></div></blockq=
uote><div><br></div><div>I want the right answer, as fast as possible, w/o =
me having to write convoluted / non-portable code because the compiler isn&=
#39;t allowed to optimize my code.=C2=A0 I want unicorns, too. :-)</div><di=
v>=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>If optimizer writers w=
ant to make an option that says &quot;assume that all<br></div><div>code ha=
s no OOE dependencies in it, and act as if the C++14 rules were</div><div>s=
till in place&quot; for those authors that write performance critical code =
where</div><div>they&#39;ve already evaluated all of the OOE dependencies, =
I&#39;d be fine with that,</div><div>as long as the behavior wasn&#39;t uns=
pecified by default. =C2=A0</div></div></blockquote><div><br></div><div>Tha=
t is beyond the purview of the standard.</div><div>=C2=A0</div><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"><div>This sounds like the</div><div>strict aliasing o=
ptions in gcc/clang.</div></div></blockquote><div><br></div><div>Which is b=
eyond the purview of the standard.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div>This is also like the difference between the fast and=
 precise floating point<br></div><div>code options in the MS VC++ compiler.=
=C2=A0 There was a thread about possibly</div><div>changing that default re=
cently, and overwhelmingly users preferred precise</div><div>over fast by d=
efault, with the option to change to fast where the author had</div><div>do=
ne the necessary analysis and testing to prove that there would be no</div>=
<div>negative effects on correctness.</div></div></blockquote><div><br></di=
v><div>I&#39;m willing to bet that most people don&#39;t understand floatin=
g point well enough to evaluate a decision like that; &quot;precise&quot; j=
ust sounds better than &quot;fast&quot;.=C2=A0 And that is also beyond the =
purview of the standard.</div><div><br></div><div><br></div><div>I&#39;m no=
t saying we shouldn&#39;t make this change, but we should do it based on da=
ta and with our eyes open, instead of pretending one side is bright and ros=
y while the other is satin&#39;s playground.</div></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevi=
n &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlo=
rd.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1=
404</div></div></div></div></div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1145a83a45718b05288a2828--

.

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

It's no pretense.  The defined order side *is* bright and rosy, while the
unspecified side *is* Satan's playground.  But as some people like to say,
the most clever thing Satan ever did is to convince people that he doesn't
exist.  He's the one whispering "optimization" and "teach people not to do
that".

On Mon, Jan 4, 2016 at 6:04 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 4 January 2016 at 16:31, Greg Marr <gregmmarr@gmail.com> wrote:
>
>> On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:
>>>
>>> On 2016-01-04 16:25, Greg Marr wrote:
>>> > What good is performance without correctness?  Don't you have to make
>>> > it work before you make it work fast?
>>>
>>> There's "correctness" and there's "correctness". Right now, there is
>>> widespread discouragement against writing order-sensitive code in the
>>> first place (in the sense of 'OOE will affect the result'). Thus, the
>>> starting assumption is that the code "works", regardless of OOE.
>>>
>>
>> I want to be sure I understand what you mean.  I see two possible
>> interpretations here:
>>
>> 1. Because of all the discouragement against writing order-sensitive
>> code, we should assume that all code that has ever been written
>> works regardless of OOE because everyone knows not to rely on it,
>> and can recognize and avoid all OOE errors.
>>
>
> If all you are going to do is bring up straw man arguments, then there is
> no point in talking about this.
>
> What the rest of us are talking about is inhibiting the compiler from
> making correct non-order dependent code fast for the sake of codifying
> currently broken code.  In the future, new order-dependent code will be
> less broken because the order is fixed.
>
> What is the impact of doing so?  I've yet to see anyone quantify it,
> produce a reasonable benchmark, etc.
>
> And there are downsides besides performance:
>
> Fixing the order will definitely break code that is accidentally dependent
> on the current order.  It doesn't magically make currently broken code
> correct, unless you happen to pick the same order.
>
> A compiler writer could not write a "parameter scrambler" to try and
> detect order-dependent code, because that would no longer be a conforming
> C++ implementation.
>
> A compiler writer could not write a sanitizer to detect order-dependent
> code, because deliberate order-dependent code is indistinguishable from
> accidental order-dependent code.
>
> Heck, a conforming compiler couldn't refuse to compile order-dependent
> code for the same reason.
>
> If we nail down the order, there is effectively no way to discourage
> writing order-dependent code.
>
> We have a very similar situation with throwing through a noexcept(true)
> function, as there is no way to distinguish between deliberately doing so
> to terminate vs. accidentally doing so to terminate.
>
> I think it is ridiculous to nail down the order and then tell people not
> to rely on it.  When has that ever worked?
>
> I don't think anyone here disagrees with this.  The question is what do
>> most authors prefer, correctness or performance?  I don't know anyone
>> who would say "I'll take the wrong answer, just give it to me fast."
>>
>
> I want the right answer, as fast as possible, w/o me having to write
> convoluted / non-portable code because the compiler isn't allowed to
> optimize my code.  I want unicorns, too. :-)
>
>
>> If optimizer writers want to make an option that says "assume that all
>> code has no OOE dependencies in it, and act as if the C++14 rules were
>> still in place" for those authors that write performance critical code
>> where
>> they've already evaluated all of the OOE dependencies, I'd be fine with
>> that,
>> as long as the behavior wasn't unspecified by default.
>>
>
> That is beyond the purview of the standard.
>
>
>> This sounds like the
>> strict aliasing options in gcc/clang.
>>
>
> Which is beyond the purview of the standard.
>
>
>> This is also like the difference between the fast and precise floating
>> point
>> code options in the MS VC++ compiler.  There was a thread about possibly
>> changing that default recently, and overwhelmingly users preferred precise
>> over fast by default, with the option to change to fast where the author
>> had
>> done the necessary analysis and testing to prove that there would be no
>> negative effects on correctness.
>>
>
> I'm willing to bet that most people don't understand floating point well
> enough to evaluate a decision like that; "precise" just sounds better than
> "fast".  And that is also beyond the purview of the standard.
>
>
> I'm not saying we shouldn't make this change, but we should do it based on
> data and with our eyes open, instead of pretending one side is bright and
> rosy while the other is satin's playground.
> --
>  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.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">It&#39;s no pretense.=C2=A0 The defined order side <i>is</=
i> bright and rosy, while the unspecified side <i>is</i> Satan&#39;s playgr=
ound.=C2=A0 But as some people like to say, the most clever thing Satan eve=
r did is to convince people that he doesn&#39;t exist.=C2=A0 He&#39;s the o=
ne whispering &quot;optimization&quot; and &quot;teach people not to do tha=
t&quot;.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Mon, Jan 4, 2016 at 6:04 PM, Nevin Liber <span dir=3D"ltr">&lt;<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 4 January 2016 at 16:31, Greg Marr <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@gmail.com</a=
>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><span class=3D""><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"><span>On Monday=
, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:<blockquote cl=
ass=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:1e=
x">On 2016-01-04 16:25, Greg Marr wrote:
<br>&gt; What good is performance without correctness?=C2=A0 Don&#39;t you =
have to make
<br>&gt; it work before you make it work fast?
<br>
<br>There&#39;s &quot;correctness&quot; and there&#39;s &quot;correctness&q=
uot;. Right now, there is
<br>widespread discouragement against writing order-sensitive code in the
<br>first place (in the sense of &#39;OOE will affect the result&#39;). Thu=
s, the
<br>starting assumption is that the code &quot;works&quot;, regardless of O=
OE.
<br></blockquote><div><br></div></span><div>I want to be sure I understand =
what you mean.=C2=A0 I see two possible</div><div>interpretations here:</di=
v><div><br></div><div>1. Because of all the discouragement against writing =
order-sensitive</div><div>code, we should assume that all code that has eve=
r been written=C2=A0</div><div>works regardless of OOE because everyone kno=
ws not to rely on it,</div><div>and can recognize and avoid all OOE errors.=
</div></div></blockquote><div><br></div></span><div>If all you are going to=
 do is bring up straw man arguments, then there is no point in talking abou=
t this.</div><div><br></div><div>What the rest of us are talking about is i=
nhibiting the compiler from making correct non-order dependent code fast fo=
r the sake of codifying currently broken code.=C2=A0 In the future, new ord=
er-dependent code will be less broken because the order is fixed.</div><div=
><br></div><div>What is the impact of doing so?=C2=A0 I&#39;ve yet to see a=
nyone quantify it, produce a reasonable benchmark, etc.</div><div><br></div=
><div>And there are downsides besides performance:</div><div><br></div><div=
>Fixing the order will definitely break code that is accidentally dependent=
 on the current order.=C2=A0 It doesn&#39;t magically make currently broken=
 code correct, unless you happen to pick the same order.<br></div><div><br>=
</div><div>A compiler writer could not write a &quot;parameter scrambler&qu=
ot; to try and detect order-dependent code, because that would no longer be=
 a conforming C++ implementation.</div><div><br></div><div>A compiler write=
r could not write a sanitizer to detect order-dependent code, because delib=
erate order-dependent code is indistinguishable from accidental order-depen=
dent code.</div><div><br></div><div>Heck, a conforming compiler couldn&#39;=
t refuse to compile order-dependent code for the same reason.</div><div><br=
></div><div>If we nail down the order, there is effectively no way to disco=
urage writing order-dependent code.</div><div><br></div><div>We have a very=
 similar situation with throwing through a noexcept(true) function, as ther=
e is no way to distinguish between deliberately doing so to terminate vs. a=
ccidentally doing so to terminate.</div><div><br></div><div>I think it is r=
idiculous to nail down the order and then tell people not to rely on it.=C2=
=A0 When has that ever worked?<br></div><span class=3D""><div><br></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"><div dir=3D"ltr"><div>I don&#39;t think anyone here disagrees=
 with this.=C2=A0 The question is what do<br></div><div>most authors prefer=
, correctness or performance?=C2=A0 I don&#39;t know anyone</div><div>who w=
ould say &quot;I&#39;ll take the wrong answer, just give it to me fast.&quo=
t;</div></div></blockquote><div><br></div></span><div>I want the right answ=
er, as fast as possible, w/o me having to write convoluted / non-portable c=
ode because the compiler isn&#39;t allowed to optimize my code.=C2=A0 I wan=
t unicorns, too. :-)</div><span class=3D""><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>If optimizer writers want to make an option that sa=
ys &quot;assume that all<br></div><div>code has no OOE dependencies in it, =
and act as if the C++14 rules were</div><div>still in place&quot; for those=
 authors that write performance critical code where</div><div>they&#39;ve a=
lready evaluated all of the OOE dependencies, I&#39;d be fine with that,</d=
iv><div>as long as the behavior wasn&#39;t unspecified by default. =C2=A0</=
div></div></blockquote><div><br></div></span><div>That is beyond the purvie=
w of the standard.</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;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div>This sounds like the</div><div>strict aliasing option=
s in gcc/clang.</div></div></blockquote><div><br></div></span><div>Which is=
 beyond the purview of the standard.</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-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr"><div>This is also like the difference be=
tween the fast and precise floating point<br></div><div>code options in the=
 MS VC++ compiler.=C2=A0 There was a thread about possibly</div><div>changi=
ng that default recently, and overwhelmingly users preferred precise</div><=
div>over fast by default, with the option to change to fast where the autho=
r had</div><div>done the necessary analysis and testing to prove that there=
 would be no</div><div>negative effects on correctness.</div></div></blockq=
uote><div><br></div></span><div>I&#39;m willing to bet that most people don=
&#39;t understand floating point well enough to evaluate a decision like th=
at; &quot;precise&quot; just sounds better than &quot;fast&quot;.=C2=A0 And=
 that is also beyond the purview of the standard.</div><div><br></div><div>=
<br></div><div>I&#39;m not saying we shouldn&#39;t make this change, but we=
 should do it based on data and with our eyes open, instead of pretending o=
ne side is bright and rosy while the other is satin&#39;s playground.</div>=
</div><span class=3D"HOEnZb"><font color=3D"#888888">-- <br><div><div dir=
=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0=
 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nev=
in@eviloverlord.com</a>&gt; =C2=A0<a href=3D"tel:%2B1-847-691-1404" value=
=3D"+18476911404" target=3D"_blank">+1-847-691-1404</a></div></div></div></=
div></div>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113dad64bd037605288a3b24--

.

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

On Mon, Jan 4, 2016 at 2:31 PM, Greg Marr <gregmmarr@gmail.com> wrote:

> On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:
>>
>>
>> Or, to put it more succinctly, defined ordering severely restricts CSE
>>
> compared to the current situation.
>
>
> I don't think anyone here disagrees with this.  The question is what do
> most authors prefer, correctness or performance?  I don't know anyone
> who would say "I'll take the wrong answer, just give it to me fast."
>
> If optimizer writers want to make an option that says "assume that all
> code has no OOE dependencies in it, and act as if the C++14 rules were
> still in place" for those authors that write performance critical code
> where
> they've already evaluated all of the OOE dependencies, I'd be fine with
> that,
> as long as the behavior wasn't unspecified by default.  This sounds like
> the
> strict aliasing options in gcc/clang.
>

Yes, although GCC's docs say, "The -fstrict-aliasing option is enabled at
levels -O2, -O3, -Os."
And of course -fstrict-aliasing is a conforming extension, whereas this
hypothetical
"-funordered-evaluation" would hypothetically *not* be conforming and
therefore
couldn't be enabled by default at any -O level.

In that respect this hypothetical "-funordered-evaluation" would be more
like
-ffast-math =E2=80=94 a non-conforming extension, provided for the benefit =
of people
with super high performance needs. (Perhaps "-funordered-evaluation" could
be enabled at level -Ofast, just as -ffast-math is.)

And yes, based on my compiler experience, this is exactly what I would
expect
to happen if, hypothetically, left-to-right evaluation order were put into
the standard.

=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">On Mon, Jan 4, 2016 at 2:31 PM, Greg Marr <span dir=3D"ltr=
">&lt;<a href=3D"mailto:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@gm=
ail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_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-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Monday, J=
anuary 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<br></blockquote></span><span class=3D""><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex">Or, to put it mor=
e succinctly, defined ordering severely restricts CSE=C2=A0<br></blockquote=
><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">compared to the current situation.=C2=A0</blockquote><div=
><br></div></span><div>I don&#39;t think anyone here disagrees with this.=
=C2=A0 The question is what do</div><div>most authors prefer, correctness o=
r performance?=C2=A0 I don&#39;t know anyone</div><div>who would say &quot;=
I&#39;ll take the wrong answer, just give it to me fast.&quot;</div><div><b=
r></div><div>If optimizer writers want to make an option that says &quot;as=
sume that all</div><div>code has no OOE dependencies in it, and act as if t=
he C++14 rules were</div><div>still in place&quot; for those authors that w=
rite performance critical code where</div><div>they&#39;ve already evaluate=
d all of the OOE dependencies, I&#39;d be fine with that,</div><div>as long=
 as the behavior wasn&#39;t unspecified by default.=C2=A0 This sounds like =
the</div><div>strict aliasing options in gcc/clang.</div></div></blockquote=
><div><br></div><div>Yes, although GCC&#39;s docs say,=C2=A0&quot;The -fstr=
ict-aliasing option is enabled at levels -O2, -O3, -Os.&quot;</div><div>And=
 of course -fstrict-aliasing is a conforming extension, whereas this hypoth=
etical</div><div>&quot;-funordered-evaluation&quot; would hypothetically <i=
>not</i> be conforming and therefore</div><div>couldn&#39;t be enabled by d=
efault at any -O level.</div><div><br></div><div>In that respect this hypot=
hetical &quot;-funordered-evaluation&quot; would be more like</div><div>-ff=
ast-math =E2=80=94 a non-conforming extension, provided for the benefit of =
people</div><div>with super high performance needs. (Perhaps &quot;-funorde=
red-evaluation&quot; could</div><div>be enabled at level -Ofast, just as -f=
fast-math is.)</div><div><br></div><div>And yes, based on my compiler exper=
ience, this is exactly what I would expect</div><div>to happen if, hypothet=
ically, left-to-right evaluation order were put into the standard.</div><di=
v><br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1140df2657a88b05288a4345--

.

------=_Part_13737_475928531.1451954751262
Content-Type: multipart/alternative;
 boundary="----=_Part_13738_48510168.1451954751275"

------=_Part_13738_48510168.1451954751275
Content-Type: text/plain; charset=UTF-8

On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On 4 January 2016 at 16:31, Greg Marr <greg...@gmail.com <javascript:>>
> wrote:
>
>> On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:
>>>
>>> On 2016-01-04 16:25, Greg Marr wrote:
>>> > What good is performance without correctness?  Don't you have to make
>>> > it work before you make it work fast?
>>>
>>> There's "correctness" and there's "correctness". Right now, there is
>>> widespread discouragement against writing order-sensitive code in the
>>> first place (in the sense of 'OOE will affect the result'). Thus, the
>>> starting assumption is that the code "works", regardless of OOE.
>>>
>>
>> I want to be sure I understand what you mean.  I see two possible
>> interpretations here:
>>
>> 1. Because of all the discouragement against writing order-sensitive
>> code, we should assume that all code that has ever been written
>> works regardless of OOE because everyone knows not to rely on it,
>> and can recognize and avoid all OOE errors.
>>
>
> If all you are going to do is bring up straw man arguments, then there is
> no point in talking about this.
>

What straw man argument?  The one where I try to understand what Matthew
means by
"the starting assumption is that the code "works", regardless of OOE."

If you didn't understand my question, I apologize for being too brief.
I was more verbose at first, but then I cut it back.  I want to know
what starting assumption and what code, so that we can actually talk
about it.

What the rest of us are talking about is inhibiting the compiler from
> making correct non-order dependent code fast for the sake of codifying
> currently broken code.  In the future, new order-dependent code will be
> less broken because the order is fixed.
>

I'm sorry, I sincerely don't understand these two sentences together.
Are you saying that you want to specify the order so that new
order-dependent code will be less broken, or that you don't want to
do that because it inhibits compiler optimizations?


> What is the impact of doing so?  I've yet to see anyone quantify it,
> produce a reasonable benchmark, etc.
>

The impact of not doing an optimization that no one currently does?


> And there are downsides besides performance:
>
> Fixing the order will definitely break code that is accidentally dependent
> on the current order.  It doesn't magically make currently broken code
> correct, unless you happen to pick the same order.
>

That's correct.  It can also be changed by such things as
changing the compiler.  It can theoretically be changed by
things such as changing the optimization level, or minor
source code changes.  Someone in this thread looked at
Clang and GCC, and they say that one always uses one
order, and one uses the other, so at least for those
particular versions of the compiler, such things won't change
the order.  We have no idea what VC++ or any other compiler
does, or how it changes from version to version.

A compiler writer could not write a "parameter scrambler" to try and detect
> order-dependent code, because that would no longer be a conforming C++
> implementation.
>

They certainly could do such a thing.  They can do anything
that they want.  It would just have to be something that is
not enabled by default.


> A compiler writer could not write a sanitizer to detect order-dependent
> code, because deliberate order-dependent code is indistinguishable from
> accidental order-dependent code.
>

They certainly could do such a thing.  There are lots of things
that compilers and especially code analysis tools such as lint
and the new code checker from MS warn about that are
perfectly valid under the standard, such as

if (i = 0)
{
}

and

Object *o = new Object;


> Heck, a conforming compiler couldn't refuse to compile order-dependent
> code for the same reason.
>

Correct, not that this is any change from the current behavior.


> If we nail down the order, there is effectively no way to discourage
> writing order-dependent code.
>

Sure there is, see above. We can discourage it the same way we
discourage naked new.

We have a very similar situation with throwing through a noexcept(true)
> function, as there is no way to distinguish between deliberately doing so
> to terminate vs. accidentally doing so to terminate.
>
> I think it is ridiculous to nail down the order and then tell people not
> to rely on it.  When has that ever worked?
>

I think it is ridiculous to simply tell people not to rely on any order.
 We know that doesn't work.

I don't think anyone here disagrees with this.  The question is what do
>> most authors prefer, correctness or performance?  I don't know anyone
>> who would say "I'll take the wrong answer, just give it to me fast."
>>
>
> I want the right answer, as fast as possible, w/o me having to write
> convoluted / non-portable code because the compiler isn't allowed to
> optimize my code.  I want unicorns, too. :-)
>

The important part there being "the right answer".  We're
currently writing non-portable code without even knowing it.


> If optimizer writers want to make an option that says "assume that all
>> code has no OOE dependencies in it, and act as if the C++14 rules were
>> still in place" for those authors that write performance critical code
>> where
>> they've already evaluated all of the OOE dependencies, I'd be fine with
>> that,
>> as long as the behavior wasn't unspecified by default.
>>
>
> That is beyond the purview of the standard.
>
>
>> This sounds like the
>> strict aliasing options in gcc/clang.
>>
>
> Which is beyond the purview of the standard.
>

I didn't say anything about the standard.  I said the
optimizer writers could give the users this option.


> This is also like the difference between the fast and precise floating
>> point
>> code options in the MS VC++ compiler.  There was a thread about possibly
>> changing that default recently, and overwhelmingly users preferred precise
>> over fast by default, with the option to change to fast where the author
>> had
>> done the necessary analysis and testing to prove that there would be no
>> negative effects on correctness.
>>
>
> I'm willing to bet that most people don't understand floating point well
> enough to evaluate a decision like that; "precise" just sounds better than
> "fast".  And that is also beyond the purview of the standard.
>

Exactly, and that is something that is currently done by
compiler writers.


> I'm not saying we shouldn't make this change, but we should do it based on
> data and with our eyes open, instead of pretending one side is bright and
> rosy while the other is satin's playground.
>

What additional data do you want that can actually be provided?
It's a theoretical optimization that no one has implemented.
How are you planning to measure that?
Do we have to put off fixing this issue until someone implements
this theoretical optimization so that someone can measure 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin &quot;:-)&quot; Liber=
 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">On 4 J=
anuary 2016 at 16:31, Greg Marr <span dir=3D"ltr">&lt;<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"AT-pQbUtEwAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D=
"this.href=3D&#39;javascript:&#39;;return true;">greg...@gmail.com</a>&gt;<=
/span> wrote:<br><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,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><span>On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woeh=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex">On 2016-01-04 16:25, Greg Marr wrote:
<br>&gt; What good is performance without correctness?=C2=A0 Don&#39;t you =
have to make
<br>&gt; it work before you make it work fast?
<br>
<br>There&#39;s &quot;correctness&quot; and there&#39;s &quot;correctness&q=
uot;. Right now, there is
<br>widespread discouragement against writing order-sensitive code in the
<br>first place (in the sense of &#39;OOE will affect the result&#39;). Thu=
s, the
<br>starting assumption is that the code &quot;works&quot;, regardless of O=
OE.
<br></blockquote><div><br></div></span><div>I want to be sure I understand =
what you mean.=C2=A0 I see two possible</div><div>interpretations here:</di=
v><div><br></div><div>1. Because of all the discouragement against writing =
order-sensitive</div><div>code, we should assume that all code that has eve=
r been written=C2=A0</div><div>works regardless of OOE because everyone kno=
ws not to rely on it,</div><div>and can recognize and avoid all OOE errors.=
</div></div></blockquote><div><br></div><div>If all you are going to do is =
bring up straw man arguments, then there is no point in talking about this.=
</div></div></div></div></blockquote><div><br></div><div>What straw man arg=
ument? =C2=A0The one where I try to understand what Matthew means by<br></d=
iv><div>&quot;the starting assumption is that the code &quot;works&quot;, r=
egardless of OOE.&quot;</div><div><br></div><div>If you didn&#39;t understa=
nd my question, I apologize for being too brief.</div><div>I was more verbo=
se at first, but then I cut it back. =C2=A0I want to know=C2=A0</div><div>w=
hat starting assumption and what code, so that we can actually talk</div><d=
iv>about it.</div><div><br></div><div><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"><div class=3D"gmail_quote">What the rest of us are talking about i=
s inhibiting the compiler from making correct non-order dependent code fast=
 for the sake of codifying currently broken code.=C2=A0 In the future, new =
order-dependent code will be less broken because the order is fixed.<br></d=
iv></div></blockquote><div><br></div><div>I&#39;m sorry, I sincerely don&#3=
9;t understand these two sentences together.</div><div>Are you saying that =
you want to specify the order so that new</div><div>order-dependent code wi=
ll be less broken, or that you don&#39;t want to</div><div>do that because =
it inhibits compiler optimizations?</div></div><div>=C2=A0</div><blockquote=
 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"><div class=3D"gmail_quot=
e"><div>What is the impact of doing so?=C2=A0 I&#39;ve yet to see anyone qu=
antify it, produce a reasonable benchmark, etc.<br></div></div></div></bloc=
kquote><div><br></div><div>The impact of not doing an optimization that no =
one currently does?</div><div>=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"><div class=3D"gmail_quote"><div></div><div=
>And there are downsides besides performance:<br></div><div><br></div><div>=
Fixing the order will definitely break code that is accidentally dependent =
on the current order.=C2=A0 It doesn&#39;t magically make currently broken =
code correct, unless you happen to pick the same order.</div></div></div></=
blockquote><div><br></div><div>That&#39;s correct. =C2=A0It can also be cha=
nged by such things as</div><div>changing the compiler. =C2=A0It can theore=
tically be changed by</div><div>things such as changing the optimization le=
vel, or minor</div><div>source code changes. =C2=A0Someone in this thread l=
ooked at</div><div>Clang and GCC, and they say that one always uses one</di=
v><div>order, and one uses the other, so at least for those</div><div>parti=
cular versions of the compiler, such things won&#39;t change</div><div>the =
order. =C2=A0We have no idea what VC++ or any other compiler</div><div>does=
, or how it changes from version to version.</div><div><br></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"><div class=3D"gmail_quo=
te"><div></div><div>A compiler writer could not write a &quot;parameter scr=
ambler&quot; to try and detect order-dependent code, because that would no =
longer be a conforming C++ implementation.<br></div></div></div></blockquot=
e><div><br></div><div>They certainly could do such a thing. =C2=A0They can =
do anything</div><div>that they want. =C2=A0It would just have to be someth=
ing that is</div><div>not enabled by default.</div><div>=C2=A0</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 class=3D"gmail_=
quote"><div></div><div>A compiler writer could not write a sanitizer to det=
ect order-dependent code, because deliberate order-dependent code is indist=
inguishable from accidental order-dependent code.<br></div></div></div></bl=
ockquote><div><br></div><div>They certainly could do such a thing. =C2=A0Th=
ere are lots of things</div><div>that compilers and especially code analysi=
s tools such as lint</div><div>and the new code checker from MS warn about =
that are=C2=A0</div><div>perfectly valid under the standard, such as</div><=
div><br></div><div>if (i =3D 0)</div><div>{</div><div>}</div><div><br></div=
><div>and=C2=A0</div><div><br></div><div>Object *o =3D new Object;</div><di=
v>=C2=A0</div><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 class=3D"gmail_quote"><div></div><div>Heck, a conforming compiler cou=
ldn&#39;t refuse to compile order-dependent code for the same reason.<br></=
div></div></div></blockquote><div><br></div><div>Correct, not that this is =
any change from the current behavior.</div><div>=C2=A0</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 class=3D"gmail_quote"><=
div></div><div>If we nail down the order, there is effectively no way to di=
scourage writing order-dependent code.<br></div></div></div></blockquote><d=
iv><br></div><div>Sure there is, see above. We can discourage it the same w=
ay we</div><div>discourage naked new.</div><div><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 class=3D"gmail_quote"><di=
v></div><div>We have a very similar situation with throwing through a noexc=
ept(true) function, as there is no way to distinguish between deliberately =
doing so to terminate vs. accidentally doing so to terminate.<br></div><div=
><br></div><div>I think it is ridiculous to nail down the order and then te=
ll people not to rely on it.=C2=A0 When has that ever worked?<br></div></di=
v></div></blockquote><div><br></div><div>I think it is ridiculous to simply=
 tell people not to rely on any order. =C2=A0We know that doesn&#39;t work.=
</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"><div class=3D"gmail_quote"><div></div><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>I don&#39;t think anyone here disagrees with this.=C2=A0 The que=
stion is what do<br></div><div>most authors prefer, correctness or performa=
nce?=C2=A0 I don&#39;t know anyone</div><div>who would say &quot;I&#39;ll t=
ake the wrong answer, just give it to me fast.&quot;</div></div></blockquot=
e><div><br></div><div>I want the right answer, as fast as possible, w/o me =
having to write convoluted / non-portable code because the compiler isn&#39=
;t allowed to optimize my code.=C2=A0 I want unicorns, too. :-)</div></div>=
</div></blockquote><div><br></div><div>The important part there being &quot=
;the right answer&quot;. =C2=A0We&#39;re</div><div>currently writing non-po=
rtable code without even knowing it.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>If optimizer writers want to make an o=
ption that says &quot;assume that all<br></div><div>code has no OOE depende=
ncies in it, and act as if the C++14 rules were</div><div>still in place&qu=
ot; for those authors that write performance critical code where</div><div>=
they&#39;ve already evaluated all of the OOE dependencies, I&#39;d be fine =
with that,</div><div>as long as the behavior wasn&#39;t unspecified by defa=
ult. =C2=A0</div></div></blockquote><div><br></div><div>That is beyond the =
purview of the standard.</div><div>=C2=A0</div><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>This sounds like the</div><div>strict aliasing options in gcc/cl=
ang.</div></div></blockquote><div><br></div><div>Which is beyond the purvie=
w of the standard.</div></div></div></blockquote><div><br></div><div>I didn=
&#39;t say anything about the standard. =C2=A0I said the</div><div>optimize=
r writers could give the users this option.</div><div>=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 class=3D"gmai=
l_quote"><div></div><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"><div>This is also lik=
e the difference between the fast and precise floating point<br></div><div>=
code options in the MS VC++ compiler.=C2=A0 There was a thread about possib=
ly</div><div>changing that default recently, and overwhelmingly users prefe=
rred precise</div><div>over fast by default, with the option to change to f=
ast where the author had</div><div>done the necessary analysis and testing =
to prove that there would be no</div><div>negative effects on correctness.<=
/div></div></blockquote><div><br></div><div>I&#39;m willing to bet that mos=
t people don&#39;t understand floating point well enough to evaluate a deci=
sion like that; &quot;precise&quot; just sounds better than &quot;fast&quot=
;.=C2=A0 And that is also beyond the purview of the standard.</div></div></=
div></blockquote><div><br></div><div>Exactly, and that is something that is=
 currently done by</div><div>compiler writers.</div><div>=C2=A0</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 class=3D"gmail=
_quote"><div>I&#39;m not saying we shouldn&#39;t make this change, but we s=
hould do it based on data and with our eyes open, instead of pretending one=
 side is bright and rosy while the other is satin&#39;s playground.<br></di=
v></div></div></blockquote><div><br></div><div>What additional data do you =
want that can actually be provided?</div><div>It&#39;s a theoretical optimi=
zation that no one has implemented.</div><div>How are you planning to measu=
re that?</div><div>Do we have to put off fixing this issue until someone im=
plements</div><div>this theoretical optimization so that someone can measur=
e it?</div><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">
</div>
</blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_13738_48510168.1451954751275--
------=_Part_13737_475928531.1451954751262--

.

------=_Part_1674_520863604.1451961087180
Content-Type: multipart/alternative;
 boundary="----=_Part_1675_1817216896.1451961087180"

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



=E5=9C=A8 2016=E5=B9=B41=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8A=E5=8D=888:45:51=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A
>
> On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote:
>
> =20
>
>> A compiler writer could not write a sanitizer to detect order-dependent=
=20
>> code, because deliberate order-dependent code is indistinguishable from=
=20
>> accidental order-dependent code.
>>
>
> They certainly could do such a thing.  There are lots of things
> that compilers and especially code analysis tools such as lint
> and the new code checker from MS warn about that are=20
> perfectly valid under the standard, such as
>
> if (i =3D 0)
> {
> }
>
> and=20
>
> Object *o =3D new Object;
> =20
>
They are different, in aspect of semantic equivalence.
=20

> If we nail down the order, there is effectively no way to discourage=20
>> writing order-dependent code.
>>
>
> Sure there is, see above. We can discourage it the same way we
> discourage naked new.
>
> There is no replacement. You have only diagnostics which can not be=20
mandated.

To discourage it like "new" - "do not use new if make_unique ... are=20
suited"? Then it should be like "do not rely on order-dependent expression=
=20
evaluation, use statements instead". This requires no change on expression=
=20
evaluation rules, also much clearer. Why need an additional subopimal way?
=20

> We have a very similar situation with throwing through a noexcept(true)=
=20
>> function, as there is no way to distinguish between deliberately doing s=
o=20
>> to terminate vs. accidentally doing so to terminate.
>>
>> I think it is ridiculous to nail down the order and then tell people not=
=20
>> to rely on it.  When has that ever worked?
>>
>
> I think it is ridiculous to simply tell people not to rely on any order.=
=20
>  We know that doesn't work.
>
> What do you expect about "work"?

If you are saying to try to make the current code correct, no one will=20
work. Wrong code are wrong by not reflecting the original intent clearly,=
=20
whatever the change of semantics rules. It is still hard to estimate the=20
cost of maintenance (if not worse).

If you are saying you can expect better code in future ... I am not=20
convinced. Most people who would get it wrong will simply not pay attention=
=20
to it, since it is always (for conforming code) or mostly (for=20
dialect-specific code) "non-breaking" to program behavior. I can only=20
expect more bugs are hidden.
=20

> I don't think anyone here disagrees with this.  The question is what do
>>> most authors prefer, correctness or performance?  I don't know anyone
>>> who would say "I'll take the wrong answer, just give it to me fast."
>>>
>>
>> I want the right answer, as fast as possible, w/o me having to write=20
>> convoluted / non-portable code because the compiler isn't allowed to=20
>> optimize my code.  I want unicorns, too. :-)
>>
>
> The important part there being "the right answer".  We're
> currently writing non-portable code without even knowing it.
> =20
>
Why are we not knowing it?
=20
Why are you here If you are not knowing it?

If optimizer writers want to make an option that says "assume that all
>>> code has no OOE dependencies in it, and act as if the C++14 rules were
>>> still in place" for those authors that write performance critical code=
=20
>>> where
>>> they've already evaluated all of the OOE dependencies, I'd be fine with=
=20
>>> that,
>>> as long as the behavior wasn't unspecified by default. =20
>>>
>>
>> That is beyond the purview of the standard.
>> =20
>>
>>> This sounds like the
>>> strict aliasing options in gcc/clang.
>>>
>>
>> Which is beyond the purview of the standard.
>>
>
> I didn't say anything about the standard.  I said the
> optimizer writers could give the users this option.
> =20
>
Things are different as a standardized language and dialects.

You have cared about "non-portable code". How code would be portable=20
without normative specification? That is the right place for standard.

This is also like the difference between the fast and precise floating poin=
t
>>> code options in the MS VC++ compiler.  There was a thread about possibl=
y
>>> changing that default recently, and overwhelmingly users preferred=20
>>> precise
>>> over fast by default, with the option to change to fast where the autho=
r=20
>>> had
>>> done the necessary analysis and testing to prove that there would be no
>>> negative effects on correctness.
>>>
>>
>> I'm willing to bet that most people don't understand floating point well=
=20
>> enough to evaluate a decision like that; "precise" just sounds better th=
an=20
>> "fast".  And that is also beyond the purview of the standard.
>>
>
> Exactly, and that is something that is currently done by
> compiler writers.
> =20
>
>> I'm not saying we shouldn't make this change, but we should do it based=
=20
>> on data and with our eyes open, instead of pretending one side is bright=
=20
>> and rosy while the other is satin's playground.
>>
>
> What additional data do you want that can actually be provided?
> It's a theoretical optimization that no one has implemented.
> How are you planning to measure that?
> Do we have to put off fixing this issue until someone implements
> this theoretical optimization so that someone can measure it?
>
> This is not the issue to *fix*. There can be fix (on expresiveness) to=20
"fix" of this issue, though.
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2016=E5=B9=B41=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=
=8C UTC+8=E4=B8=8A=E5=8D=888:45:51=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=
=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, January 4, 20=
16 at 6:05:33 PM UTC-5, Nevin &quot;:-)&quot; Liber wrote:<div><br></div><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"><div class=3D"gmail_=
quote"><div></div></div></div></blockquote><div>=C2=A0</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 class=3D"gmail_quote"><div><=
/div><div>A compiler writer could not write a sanitizer to detect order-dep=
endent code, because deliberate order-dependent code is indistinguishable f=
rom accidental order-dependent code.<br></div></div></div></blockquote><div=
><br></div><div>They certainly could do such a thing. =C2=A0There are lots =
of things</div><div>that compilers and especially code analysis tools such =
as lint</div><div>and the new code checker from MS warn about that are=C2=
=A0</div><div>perfectly valid under the standard, such as</div><div><br></d=
iv><div>if (i =3D 0)</div><div>{</div><div>}</div><div><br></div><div>and=
=C2=A0</div><div><br></div><div>Object *o =3D new Object;</div><div>=C2=A0<=
/div></blockquote><div>They are different, in aspect of semantic equivalenc=
e.<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;"><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"><div class=3D"gmail_quote"=
><div></div><div>If we nail down the order, there is effectively no way to =
discourage writing order-dependent code.<br></div></div></div></blockquote>=
<div><br></div><div>Sure there is, see above. We can discourage it the same=
 way we</div><div>discourage naked new.</div><div><br></div></blockquote><d=
iv>There is no replacement. You have only diagnostics which can not be mand=
ated.<br><br>To discourage it like &quot;new&quot; - &quot;do not use new i=
f make_unique ... are suited&quot;? Then it should be like &quot;do not rel=
y on order-dependent expression evaluation, use statements instead&quot;. T=
his requires no change on expression evaluation rules, also much clearer. W=
hy need an additional subopimal way?<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></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><div>We have a v=
ery similar situation with throwing through a noexcept(true) function, as t=
here is no way to distinguish between deliberately doing so to terminate vs=
.. accidentally doing so to terminate.<br></div><div><br></div><div>I think =
it is ridiculous to nail down the order and then tell people not to rely on=
 it.=C2=A0 When has that ever worked?<br></div></div></div></blockquote><di=
v><br></div><div>I think it is ridiculous to simply tell people not to rely=
 on any order. =C2=A0We know that doesn&#39;t work.</div><div><br></div></b=
lockquote><div>What do you expect about &quot;work&quot;?<br><br>If you are=
 saying to try to make the current code correct, no one will work. Wrong co=
de are wrong by not reflecting the original intent clearly, whatever the ch=
ange of semantics rules. It is still hard to estimate the cost of maintenan=
ce (if not worse).<br><br>If you are saying you can expect better code in f=
uture ... I am not convinced. Most people who would get it wrong will simpl=
y not pay attention to it, since it is always (for conforming code) or most=
ly (for dialect-specific code) &quot;non-breaking&quot; to program behavior=
.. I can only expect more bugs are hidden.<br>=C2=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><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>I don&#39;t think anyone here disagrees with this=
..=C2=A0 The question is what do<br></div><div>most authors prefer, correctn=
ess or performance?=C2=A0 I don&#39;t know anyone</div><div>who would say &=
quot;I&#39;ll take the wrong answer, just give it to me fast.&quot;</div></=
div></blockquote><div><br></div><div>I want the right answer, as fast as po=
ssible, w/o me having to write convoluted / non-portable code because the c=
ompiler isn&#39;t allowed to optimize my code.=C2=A0 I want unicorns, too. =
:-)</div></div></div></blockquote><div><br></div><div>The important part th=
ere being &quot;the right answer&quot;. =C2=A0We&#39;re</div><div>currently=
 writing non-portable code without even knowing it.</div><div>=C2=A0</div><=
/blockquote><div>Why are we not knowing it?<br>=C2=A0<br>Why are you here I=
f you are not knowing it?<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><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 clas=
s=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"><div dir=3D"ltr"><div>If optimizer write=
rs want to make an option that says &quot;assume that all<br></div><div>cod=
e has no OOE dependencies in it, and act as if the C++14 rules were</div><d=
iv>still in place&quot; for those authors that write performance critical c=
ode where</div><div>they&#39;ve already evaluated all of the OOE dependenci=
es, I&#39;d be fine with that,</div><div>as long as the behavior wasn&#39;t=
 unspecified by default. =C2=A0</div></div></blockquote><div><br></div><div=
>That is beyond the purview of the standard.</div><div>=C2=A0</div><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>This sounds like the</div><div>strict aliasi=
ng options in gcc/clang.</div></div></blockquote><div><br></div><div>Which =
is beyond the purview of the standard.</div></div></div></blockquote><div><=
br></div><div>I didn&#39;t say anything about the standard. =C2=A0I said th=
e</div><div>optimizer writers could give the users this option.</div><div>=
=C2=A0<br></div></blockquote><div>Things are different as a standardized la=
nguage and dialects.<br><br>You have cared about &quot;non-portable code&qu=
ot;. How code would be portable without normative specification? That is th=
e right place for standard.<br><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></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"l=
tr"><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-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"=
><div>This is also like the difference between the fast and precise floatin=
g point<br></div><div>code options in the MS VC++ compiler.=C2=A0 There was=
 a thread about possibly</div><div>changing that default recently, and over=
whelmingly users preferred precise</div><div>over fast by default, with the=
 option to change to fast where the author had</div><div>done the necessary=
 analysis and testing to prove that there would be no</div><div>negative ef=
fects on correctness.</div></div></blockquote><div><br></div><div>I&#39;m w=
illing to bet that most people don&#39;t understand floating point well eno=
ugh to evaluate a decision like that; &quot;precise&quot; just sounds bette=
r than &quot;fast&quot;.=C2=A0 And that is also beyond the purview of the s=
tandard.</div></div></div></blockquote><div><br></div><div>Exactly, and tha=
t is something that is currently done by</div><div>compiler writers.</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"><d=
iv class=3D"gmail_quote"><div>I&#39;m not saying we shouldn&#39;t make this=
 change, but we should do it based on data and with our eyes open, instead =
of pretending one side is bright and rosy while the other is satin&#39;s pl=
ayground.<br></div></div></div></blockquote><div><br></div><div>What additi=
onal data do you want that can actually be provided?</div><div>It&#39;s a t=
heoretical optimization that no one has implemented.</div><div>How are you =
planning to measure that?</div><div>Do we have to put off fixing this issue=
 until someone implements</div><div>this theoretical optimization so that s=
omeone can measure it?</div><div><br></div></blockquote><div>This is not th=
e issue to <i>fix</i>. There can be fix (on expresiveness) to &quot;fix&quo=
t; of this issue, though.<br>=C2=A0<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1675_1817216896.1451961087180--
------=_Part_1674_520863604.1451961087180--

.

------=_Part_409_578108975.1451964501685
Content-Type: multipart/alternative;
 boundary="----=_Part_410_616069637.1451964501686"

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

On Monday, January 4, 2016 at 9:31:27 PM UTC-5, FrankHB1989 wrote:
>
> =E5=9C=A8 2016=E5=B9=B41=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UT=
C+8=E4=B8=8A=E5=8D=888:45:51=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A
>>
>> On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote:
>>>
>>> A compiler writer could not write a sanitizer to detect order-dependent=
=20
>>> code, because deliberate order-dependent code is indistinguishable from=
=20
>>> accidental order-dependent code.
>>>
>>
>> They certainly could do such a thing.  There are lots of things
>> that compilers and especially code analysis tools such as lint
>> and the new code checker from MS warn about that are=20
>> perfectly valid under the standard, such as
>>
>> if (i =3D 0)
>> {
>> }
>>
>> and=20
>>
>> Object *o =3D new Object;
>> =20
>>
> They are different, in aspect of semantic equivalence.
>

In what way?  They're all things that the standard says are perfectly
legal, but are things that are not recommended as they are difficult
to get right.

If we nail down the order, there is effectively no way to discourage=20
>>> writing order-dependent code.
>>>
>>
>> Sure there is, see above. We can discourage it the same way we
>> discourage naked new.
>>
>> There is no replacement. You have only diagnostics which can not be=20
> mandated.
>

Same as both of the cases above that tools already warn about.  There is no
way to discourage them short of diagnostics that can not be mandated.
=20

> To discourage it like "new" - "do not use new if make_unique ... are=20
> suited"? Then it should be like "do not rely on order-dependent expressio=
n=20
> evaluation, use statements instead". This requires no change on expressio=
n=20
> evaluation rules, also much clearer. Why need an additional subopimal way=
?
>

So that there are no portability problems because of non-deterministic
behavior with the code as written, even if the tool doesn't recognize
that there is a potential order of evaluation issue.
=20

> =20
>
>> We have a very similar situation with throwing through a noexcept(true)=
=20
>>> function, as there is no way to distinguish between deliberately doing =
so=20
>>> to terminate vs. accidentally doing so to terminate.
>>>
>>> I think it is ridiculous to nail down the order and then tell people no=
t=20
>>> to rely on it.  When has that ever worked?
>>>
>>
>> I think it is ridiculous to simply tell people not to rely on any order.=
=20
>>  We know that doesn't work.
>>
>> What do you expect about "work"?
>

That people follow the advice and don't write code that has
unspecified behavior.  They do it now because they either ignore
the advice, or because they don't know that their code has
unspecified behavior, or both.

If you are saying to try to make the current code correct, no one will=20
> work. Wrong code are wrong by not reflecting the original intent clearly,=
=20
> whatever the change of semantics rules. It is still hard to estimate the=
=20
> cost of maintenance (if not worse).
>
> If you are saying you can expect better code in future ... I am not=20
> convinced. Most people who would get it wrong will simply not pay attenti=
on=20
> to it, since it is always (for conforming code) or mostly (for=20
> dialect-specific code) "non-breaking" to program behavior. I can only=20
> expect more bugs are hidden.
>

If the same code always produces the same result under all
compilers and optimization settings, then the unexpected result
has a much better chance of being noticed right away, instead of=20
being silently wrong until the order of evaluation changes, at which
time the code in question is probably not being actively developed,
and so may not be tested in such a way as to expose the bug.

=20
>
>> I don't think anyone here disagrees with this.  The question is what do
>>>> most authors prefer, correctness or performance?  I don't know anyone
>>>> who would say "I'll take the wrong answer, just give it to me fast."
>>>>
>>>
>>> I want the right answer, as fast as possible, w/o me having to write=20
>>> convoluted / non-portable code because the compiler isn't allowed to=20
>>> optimize my code.  I want unicorns, too. :-)
>>>
>>
>> The important part there being "the right answer".  We're
>> currently writing non-portable code without even knowing it.
>>
> Why are we not knowing it?
>
=20

> Why are you here If you are not knowing it?
>

Because it's not always obvious.  Have you not seen the posts
in this thread about the code which existed in print for many
years, read by many language experts, before the order of
evaluation errors were found?=20


> If optimizer writers want to make an option that says "assume that all
>>>> code has no OOE dependencies in it, and act as if the C++14 rules were
>>>> still in place" for those authors that write performance critical code=
=20
>>>> where
>>>> they've already evaluated all of the OOE dependencies, I'd be fine wit=
h=20
>>>> that,
>>>> as long as the behavior wasn't unspecified by default. =20
>>>>
>>>
>>> That is beyond the purview of the standard.
>>> =20
>>>
>>>> This sounds like the
>>>> strict aliasing options in gcc/clang.
>>>>
>>>
>>> Which is beyond the purview of the standard.
>>>
>>
>> I didn't say anything about the standard.  I said the
>> optimizer writers could give the users this option.
>> =20
>>
> Things are different as a standardized language and dialects.
>
> You have cared about "non-portable code". How code would be portable=20
> without normative specification? That is the right place for standard.
>

Yes, the code is portable.  This is talking about enabling a
potential future optimization that, when used properly, allows
the optimizer to make certain assumptions about the code
that the standard as a whole wouldn't otherwise allow, namely
reordering operations that in C++14 are unsequenced, but were=20
later defined to have a given sequence.  I mention this only
because people are worried that this eliminates the ability of
a theoretical optimizer to reorder operations in a way that
provides better performance in cases where the author knows
that the code is correct under the C++14 rules.  I don't have
a need for it or see that I would use it in any of my projects.
=20

>
> This is also like the difference between the fast and precise floating=20
>>>> point
>>>> code options in the MS VC++ compiler.  There was a thread about possib=
ly
>>>> changing that default recently, and overwhelmingly users preferred=20
>>>> precise
>>>> over fast by default, with the option to change to fast where the=20
>>>> author had
>>>> done the necessary analysis and testing to prove that there would be n=
o
>>>> negative effects on correctness.
>>>>
>>>
>>> I'm willing to bet that most people don't understand floating point wel=
l=20
>>> enough to evaluate a decision like that; "precise" just sounds better t=
han=20
>>> "fast".  And that is also beyond the purview of the standard.
>>>
>>
>> Exactly, and that is something that is currently done by
>> compiler writers.
>> =20
>>
>>> I'm not saying we shouldn't make this change, but we should do it based=
=20
>>> on data and with our eyes open, instead of pretending one side is brigh=
t=20
>>> and rosy while the other is satin's playground.
>>>
>>
>> What additional data do you want that can actually be provided?
>> It's a theoretical optimization that no one has implemented.
>> How are you planning to measure that?
>> Do we have to put off fixing this issue until someone implements
>> this theoretical optimization so that someone can measure it?
>>
>> This is not the issue to *fix*. There can be fix (on expresiveness) to=
=20
> "fix" of this issue, though.
>

Sorry, I don't understand this sentence.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

On Monday, January 4, 2016 at 9:31:27 PM UTC-5, FrankHB1989 wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">=E5=9C=A8 2016=E5=B9=B41=E6=9C=885=E6=
=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=888:45:51=EF=BC=8CGr=
eg Marr=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"=
>On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin &quot;:-)&quot; Libe=
r 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"><div class=
=3D"gmail_quote">A compiler writer could not write a sanitizer to detect or=
der-dependent code, because deliberate order-dependent code is indistinguis=
hable from accidental order-dependent code.<br></div></div></blockquote><di=
v><br></div><div>They certainly could do such a thing. =C2=A0There are lots=
 of things</div><div>that compilers and especially code analysis tools such=
 as lint</div><div>and the new code checker from MS warn about that are=C2=
=A0</div><div>perfectly valid under the standard, such as</div><div><br></d=
iv><div>if (i =3D 0)</div><div>{</div><div>}</div><div><br></div><div>and=
=C2=A0</div><div><br></div><div>Object *o =3D new Object;</div><div>=C2=A0<=
/div></blockquote><div>They are different, in aspect of semantic equivalenc=
e.<br></div></blockquote><div><br></div><div>In what way? =C2=A0They&#39;re=
 all things that the standard says are perfectly</div><div>legal, but are t=
hings that are not recommended as they are difficult</div><div>to get right=
..</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_quote"><div>If we nail down the order, th=
ere is effectively no way to discourage writing order-dependent code.<br></=
div></div></div></blockquote><div><br></div><div>Sure there is, see above. =
We can discourage it the same way we</div><div>discourage naked new.</div><=
div><br></div></blockquote><div>There is no replacement. You have only diag=
nostics which can not be mandated.<br></div></blockquote><div><br></div><di=
v>Same as both of the cases above that tools already warn about. =C2=A0Ther=
e is no</div><div>way to discourage them short of diagnostics that can not =
be mandated.</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>To discourage it like &quot;new&quot; - &quot;do not use new if =
make_unique ... are suited&quot;? Then it should be like &quot;do not rely =
on order-dependent expression evaluation, use statements instead&quot;. Thi=
s requires no change on expression evaluation rules, also much clearer. Why=
 need an additional subopimal way?<br></div></blockquote><div><br></div><di=
v>So that there are no portability problems because of non-deterministic</d=
iv><div>behavior with the code as written, even if the tool doesn&#39;t rec=
ognize</div><div>that there is a potential order of evaluation issue.</div>=
<div>=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>=C2=A0<b=
r></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><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 class=3D"gmail_quote"><div></=
div><div>We have a very similar situation with throwing through a noexcept(=
true) function, as there is no way to distinguish between deliberately doin=
g so to terminate vs. accidentally doing so to terminate.<br></div><div><br=
></div><div>I think it is ridiculous to nail down the order and then tell p=
eople not to rely on it.=C2=A0 When has that ever worked?<br></div></div></=
div></blockquote><div><br></div><div>I think it is ridiculous to simply tel=
l people not to rely on any order. =C2=A0We know that doesn&#39;t work.</di=
v><div><br></div></blockquote><div>What do you expect about &quot;work&quot=
;?<br></div></blockquote><div><br></div><div>That people follow the advice =
and don&#39;t write code that has</div><div>unspecified behavior. =C2=A0The=
y do it now because they either ignore</div><div>the advice, or because the=
y don&#39;t know that their code has</div><div>unspecified behavior, or bot=
h.</div><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>If=
 you are saying to try to make the current code correct, no one will work. =
Wrong code are wrong by not reflecting the original intent clearly, whateve=
r the change of semantics rules. It is still hard to estimate the cost of m=
aintenance (if not worse).<br><br>If you are saying you can expect better c=
ode in future ... I am not convinced. Most people who would get it wrong wi=
ll simply not pay attention to it, since it is always (for conforming code)=
 or mostly (for dialect-specific code) &quot;non-breaking&quot; to program =
behavior. I can only expect more bugs are hidden.<br></div></blockquote><di=
v><br></div><div>If the same code always produces the same result under all=
</div><div>compilers and optimization settings, then the unexpected result<=
/div><div>has a much better chance of being noticed right away, instead of=
=C2=A0</div><div>being silently wrong until the order of evaluation changes=
, at which</div><div>time the code in question is probably not being active=
ly developed,</div><div>and so may not be tested in such a way as to expose=
 the bug.</div><div><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>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><bl=
ockquote 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 class=3D"gmail_q=
uote"><div></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-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>I don&#39;t think a=
nyone here disagrees with this.=C2=A0 The question is what do<br></div><div=
>most authors prefer, correctness or performance?=C2=A0 I don&#39;t know an=
yone</div><div>who would say &quot;I&#39;ll take the wrong answer, just giv=
e it to me fast.&quot;</div></div></blockquote><div><br></div><div>I want t=
he right answer, as fast as possible, w/o me having to write convoluted / n=
on-portable code because the compiler isn&#39;t allowed to optimize my code=
..=C2=A0 I want unicorns, too. :-)</div></div></div></blockquote><div><br></=
div><div>The important part there being &quot;the right answer&quot;. =C2=
=A0We&#39;re</div><div>currently writing non-portable code without even kno=
wing it.</div></blockquote><div>Why are we not knowing it?<br></div></block=
quote><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;"><di=
v>Why are you here If you are not knowing it?<br></div></blockquote><div><b=
r></div><div>Because it&#39;s not always obvious. =C2=A0Have you not seen t=
he posts</div><div>in this thread about the code which existed in print for=
 many</div><div>years, read by many language experts, before the order of</=
div><div>evaluation errors were found?=C2=A0</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div><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"><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"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>If optimizer=
 writers want to make an option that says &quot;assume that all<br></div><d=
iv>code has no OOE dependencies in it, and act as if the C++14 rules were</=
div><div>still in place&quot; for those authors that write performance crit=
ical code where</div><div>they&#39;ve already evaluated all of the OOE depe=
ndencies, I&#39;d be fine with that,</div><div>as long as the behavior wasn=
&#39;t unspecified by default. =C2=A0</div></div></blockquote><div><br></di=
v><div>That is beyond the purview of the standard.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>This sounds like the</div><div>strict =
aliasing options in gcc/clang.</div></div></blockquote><div><br></div><div>=
Which is beyond the purview of the standard.</div></div></div></blockquote>=
<div><br></div><div>I didn&#39;t say anything about the standard. =C2=A0I s=
aid the</div><div>optimizer writers could give the users this option.</div>=
<div>=C2=A0<br></div></blockquote><div>Things are different as a standardiz=
ed language and dialects.<br><br>You have cared about &quot;non-portable co=
de&quot;. How code would be portable without normative specification? That =
is the right place for standard.<br></div></blockquote><div><br></div><div>=
Yes, the code is portable. =C2=A0This is talking about enabling a</div><div=
>potential future optimization that, when used properly, allows</div><div>t=
he optimizer to make certain assumptions about the code</div><div>that the =
standard as a whole wouldn&#39;t otherwise allow, namely</div><div>reorderi=
ng operations that in C++14 are unsequenced, but were=C2=A0</div><div>later=
 defined to have a given sequence. =C2=A0I mention this only</div><div>beca=
use people are worried that this eliminates the ability of</div><div>a theo=
retical optimizer to reorder operations in a way that</div><div>provides be=
tter performance in cases where the author knows</div><div>that the code is=
 correct under the C++14 rules. =C2=A0I don&#39;t have</div><div>a need for=
 it or see that I would use it in any of my projects.</div><div>=C2=A0<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><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 class=3D"gmail_quote"><div></div><blockquote cl=
ass=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:1e=
x"><div dir=3D"ltr"><div>This is also like the difference between the fast =
and precise floating point<br></div><div>code options in the MS VC++ compil=
er.=C2=A0 There was a thread about possibly</div><div>changing that default=
 recently, and overwhelmingly users preferred precise</div><div>over fast b=
y default, with the option to change to fast where the author had</div><div=
>done the necessary analysis and testing to prove that there would be no</d=
iv><div>negative effects on correctness.</div></div></blockquote><div><br><=
/div><div>I&#39;m willing to bet that most people don&#39;t understand floa=
ting point well enough to evaluate a decision like that; &quot;precise&quot=
; just sounds better than &quot;fast&quot;.=C2=A0 And that is also beyond t=
he purview of the standard.</div></div></div></blockquote><div><br></div><d=
iv>Exactly, and that is something that is currently done by</div><div>compi=
ler writers.</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"><div class=3D"gmail_quote"><div>I&#39;m not saying we sho=
uldn&#39;t make this change, but we should do it based on data and with our=
 eyes open, instead of pretending one side is bright and rosy while the oth=
er is satin&#39;s playground.<br></div></div></div></blockquote><div><br></=
div><div>What additional data do you want that can actually be provided?</d=
iv><div>It&#39;s a theoretical optimization that no one has implemented.</d=
iv><div>How are you planning to measure that?</div><div>Do we have to put o=
ff fixing this issue until someone implements</div><div>this theoretical op=
timization so that someone can measure it?</div><div><br></div></blockquote=
><div>This is not the issue to <i>fix</i>. There can be fix (on expresivene=
ss) to &quot;fix&quot; of this issue, though.<br></div></blockquote><div><b=
r></div><div>Sorry, I don&#39;t understand this sentence.</div><div><br></d=
iv>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_410_616069637.1451964501686--
------=_Part_409_578108975.1451964501685--

.

------=_Part_6904_939231743.1451972125637
Content-Type: multipart/alternative;
 boundary="----=_Part_6905_889231081.1451972125638"

------=_Part_6905_889231081.1451972125638
Content-Type: text/plain; charset=UTF-8

On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On 4 January 2016 at 16:31, Greg Marr <greg...@gmail.com <javascript:>>
> wrote:
>
>> On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:
>>>
>>> On 2016-01-04 16:25, Greg Marr wrote:
>>> > What good is performance without correctness?  Don't you have to make
>>> > it work before you make it work fast?
>>>
>>> There's "correctness" and there's "correctness". Right now, there is
>>> widespread discouragement against writing order-sensitive code in the
>>> first place (in the sense of 'OOE will affect the result'). Thus, the
>>> starting assumption is that the code "works", regardless of OOE.
>>>
>>
>> I want to be sure I understand what you mean.  I see two possible
>> interpretations here:
>>
>> 1. Because of all the discouragement against writing order-sensitive
>> code, we should assume that all code that has ever been written
>> works regardless of OOE because everyone knows not to rely on it,
>> and can recognize and avoid all OOE errors.
>>
>
> If all you are going to do is bring up straw man arguments, then there is
> no point in talking about this.
>
> What the rest of us are talking about is inhibiting the compiler from
> making correct non-order dependent code fast for the sake of codifying
> currently broken code.  In the future, new order-dependent code will be
> less broken because the order is fixed.
>
> What is the impact of doing so?  I've yet to see anyone quantify it,
> produce a reasonable benchmark, etc.
>

No, we have quantified it. The impact is, as far as we have determined...
zero.

We have actual evidence in hand that many widely used compilers do not make
such optimizations. As such, the impact of such a change on those compilers
will be nothing.

"In the future" is not "today". It's not "now". There is no way to quantify
what *could happen* in the future. Why should we prepare for some future
that may never happen, when we can instead deal with problems we already
have?


> And there are downsides besides performance:
>
> Fixing the order will definitely break code that is accidentally dependent
> on the current order.  It doesn't magically make currently broken code
> correct, unless you happen to pick the same order.
>

Broken code is broken code, even if you didn't know it was broken before.
This would be no different from having those people port their code to
other platforms with a different ordering. Indeed, it would be no different
from having a compiler vendor unilaterally decide to change their ordering
in one compiler version.

A compiler writer could not write a "parameter scrambler" to try and detect
> order-dependent code, because that would no longer be a conforming C++
> implementation.
>

.... If you're going to complain about strawmen, it's a good idea not to
make one yourself. In a world where order-dependent code has a single,
unambiguous meaning, you *don't need* such a tool. Your code has a
well-defined result across all platforms.

A compiler writer could not write a sanitizer to detect order-dependent
> code, because deliberate order-dependent code is indistinguishable from
> accidental order-dependent code.
>

See above.

Also, compilers warn about `if(x = ...)`, but they don't warn about `if((x
= ...))`. That's a convention that was developed so that users could tell
the compiler that they really meant to do that. Nothing was standardized
for it, but different compiler developers implemented it all the same.

There's no reason something similar couldn't happen. Maybe an attribute
applied to the overall expression or some-such. If such a thing were needed.

Heck, a conforming compiler couldn't refuse to compile order-dependent code
> for the same reason.
>

A "conforming compiler" shouldn't refuse to compile valid C++ code *period*.
And if you turn warnings into errors, you've already decide that there's
conforming code that will be rejected. Why would this be any different? It
would just be another warning.

If we nail down the order, there is effectively no way to discourage
> writing order-dependent code.
>

Order-dependent code, in a world where the order is fixed, is not *a priori*
wrong. Indeed, part of the point of nailing down an order is so that people
*can* write code that relies on it. So that you can look at a piece of code
and know exactly what it does, even if some process modifies a non-local
variable.


> We have a very similar situation with throwing through a noexcept(true)
> function, as there is no way to distinguish between deliberately doing so
> to terminate vs. accidentally doing so to terminate.
>
> I think it is ridiculous to nail down the order and then tell people not
> to rely on it.
>

I agree. If we nail down the order, people will write more order dependent
code. What I disagree on is the idea that this would be a bad thing.

The bad thing is if people start writing *obtuse* code, where the meaning
is obscured by order dependency in some way. Not all order dependent code
is unintelligable garbage.

>
>
> I don't think anyone here disagrees with this.  The question is what do
>> most authors prefer, correctness or performance?  I don't know anyone
>> who would say "I'll take the wrong answer, just give it to me fast."
>>
>
> I want the right answer, as fast as possible, w/o me having to write
> convoluted / non-portable code because the compiler isn't allowed to
> optimize my code.  I want unicorns, too. :-)
>


> If optimizer writers want to make an option that says "assume that all
>> code has no OOE dependencies in it, and act as if the C++14 rules were
>> still in place" for those authors that write performance critical code
>> where
>> they've already evaluated all of the OOE dependencies, I'd be fine with
>> that,
>> as long as the behavior wasn't unspecified by default.
>>
>
> That is beyond the purview of the standard.
>
>
>> This sounds like the
>> strict aliasing options in gcc/clang.
>>
>
> Which is beyond the purview of the standard.
>

That hasn't people from writing code that requires those flags.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin &quot;:-)&quot; Liber=
 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">On 4 J=
anuary 2016 at 16:31, Greg Marr <span dir=3D"ltr">&lt;<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"AT-pQbUtEwAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D=
"this.href=3D&#39;javascript:&#39;;return true;">greg...@gmail.com</a>&gt;<=
/span> wrote:<br><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,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><span>On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woeh=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex">On 2016-01-04 16:25, Greg Marr wrote:
<br>&gt; What good is performance without correctness?=C2=A0 Don&#39;t you =
have to make
<br>&gt; it work before you make it work fast?
<br>
<br>There&#39;s &quot;correctness&quot; and there&#39;s &quot;correctness&q=
uot;. Right now, there is
<br>widespread discouragement against writing order-sensitive code in the
<br>first place (in the sense of &#39;OOE will affect the result&#39;). Thu=
s, the
<br>starting assumption is that the code &quot;works&quot;, regardless of O=
OE.
<br></blockquote><div><br></div></span><div>I want to be sure I understand =
what you mean.=C2=A0 I see two possible</div><div>interpretations here:</di=
v><div><br></div><div>1. Because of all the discouragement against writing =
order-sensitive</div><div>code, we should assume that all code that has eve=
r been written=C2=A0</div><div>works regardless of OOE because everyone kno=
ws not to rely on it,</div><div>and can recognize and avoid all OOE errors.=
</div></div></blockquote><div><br></div><div>If all you are going to do is =
bring up straw man arguments, then there is no point in talking about this.=
</div><div><br></div><div>What the rest of us are talking about is inhibiti=
ng the compiler from making correct non-order dependent code fast for the s=
ake of codifying currently broken code.=C2=A0 In the future, new order-depe=
ndent code will be less broken because the order is fixed.</div><div><br></=
div><div>What is the impact of doing so?=C2=A0 I&#39;ve yet to see anyone q=
uantify it, produce a reasonable benchmark, etc.</div></div></div></div></b=
lockquote><div><br>No, we have quantified it. The impact is, as far as we h=
ave determined... zero.<br><br>We have actual evidence in hand that many wi=
dely used compilers do not make such optimizations. As such, the impact of =
such a change on those compilers will be nothing.<br><br>&quot;In the futur=
e&quot; is not &quot;today&quot;. It&#39;s not &quot;now&quot;. There is no=
 way to quantify what <i>could happen</i> in the future. Why should we prep=
are for some future that may never happen, when we can instead deal with pr=
oblems we already have?<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>A=
nd there are downsides besides performance:</div><div><br></div><div>Fixing=
 the order will definitely break code that is accidentally dependent on the=
 current order.=C2=A0 It doesn&#39;t magically make currently broken code c=
orrect, unless you happen to pick the same order.<br></div></div></div></di=
v></blockquote><div><br>Broken code is broken code, even if you didn&#39;t =
know it was broken before. This would be no different from having those peo=
ple port their code to other platforms with a different ordering. Indeed, i=
t would be no different from having a compiler vendor unilaterally decide t=
o change their ordering in one compiler version.<br><br></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></div><div></div><div>A compiler writer could not write a &quot;=
parameter scrambler&quot; to try and detect order-dependent code, because t=
hat would no longer be a conforming C++ implementation.</div></div></div></=
div></blockquote><div><br>... If you&#39;re going to complain about strawme=
n, it&#39;s a good idea not to make one yourself. In a world where order-de=
pendent code has a single, unambiguous meaning, you <i>don&#39;t need</i> s=
uch a tool. Your code has a well-defined result across all platforms.<br><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><div>A compiler writer could not writ=
e a sanitizer to detect order-dependent code, because deliberate order-depe=
ndent code is indistinguishable from accidental order-dependent code.</div>=
</div></div></div></blockquote><div><br>See above.<br><br>Also, compilers w=
arn about `if(x =3D ...)`, but they don&#39;t warn about `if((x =3D ...))`.=
 That&#39;s a convention that was developed so that users could tell the co=
mpiler that they really meant to do that. Nothing was standardized for it, =
but different compiler developers implemented it all the same.<br><br>There=
&#39;s no reason something similar couldn&#39;t happen. Maybe an attribute =
applied to the overall expression or some-such. If such a thing were needed=
..<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 class=3D"gmail_quote"><div></div><div>Heck, a conforming compil=
er couldn&#39;t refuse to compile order-dependent code for the same reason.=
</div></div></div></div></blockquote><div><br>A &quot;conforming compiler&q=
uot; shouldn&#39;t refuse to compile valid C++ code <i>period</i>. And if y=
ou turn warnings into errors, you&#39;ve already decide that there&#39;s co=
nforming code that will be rejected. Why would this be any different? It wo=
uld just be another warning.<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 class=3D"gmail_quote"><div></div><di=
v>If we nail down the order, there is effectively no way to discourage writ=
ing order-dependent code.</div></div></div></div></blockquote><div><br>Orde=
r-dependent code, in a world where the order is fixed, is not <i>a priori</=
i> wrong. Indeed, part of the point of nailing down an order is so that peo=
ple <i>can</i> write code that relies on it. So that you can look at a piec=
e of code and know exactly what it does, even if some process modifies a no=
n-local variable.<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><div>We have=
 a very similar situation with throwing through a noexcept(true) function, =
as there is no way to distinguish between deliberately doing so to terminat=
e vs. accidentally doing so to terminate.</div><div><br></div><div>I think =
it is ridiculous to nail down the order and then tell people not to rely on=
 it.</div></div></div></div></blockquote><div><br>I agree. If we nail down =
the order, people will write more order dependent code. What I disagree on =
is the idea that this would be a bad thing. <br><br>The bad thing is if peo=
ple start writing <i>obtuse</i> code, where the meaning is obscured by orde=
r dependency in some way. Not all order dependent code is unintelligable ga=
rbage.</div>=C2=A0<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><div><br></div><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"><div>I don&#39;t think anyone here disagrees with thi=
s.=C2=A0 The question is what do<br></div><div>most authors prefer, correct=
ness or performance?=C2=A0 I don&#39;t know anyone</div><div>who would say =
&quot;I&#39;ll take the wrong answer, just give it to me fast.&quot;</div><=
/div></blockquote><div><br></div><div>I want the right answer, as fast as p=
ossible, w/o me having to write convoluted / non-portable code because the =
compiler isn&#39;t allowed to optimize my code.=C2=A0 I want unicorns, too.=
 :-)</div></div></div></div></blockquote><div>=C2=A0</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><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div dir=3D"ltr"><div>If optimizer writers want to make =
an option that says &quot;assume that all<br></div><div>code has no OOE dep=
endencies in it, and act as if the C++14 rules were</div><div>still in plac=
e&quot; for those authors that write performance critical code where</div><=
div>they&#39;ve already evaluated all of the OOE dependencies, I&#39;d be f=
ine with that,</div><div>as long as the behavior wasn&#39;t unspecified by =
default. =C2=A0</div></div></blockquote><div><br></div><div>That is beyond =
the purview of the standard.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr"><div>This sounds like the</div><div>strict aliasing options in gc=
c/clang.</div></div></blockquote><div><br></div><div>Which is beyond the pu=
rview of the standard.</div></div></div></div></blockquote><div><br>That ha=
sn&#39;t people from writing code that requires those flags.</div><br>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_6905_889231081.1451972125638--
------=_Part_6904_939231743.1451972125637--

.

------=_Part_580_1445478483.1451972196712
Content-Type: multipart/alternative;
 boundary="----=_Part_581_1005519067.1451972196712"

------=_Part_581_1005519067.1451972196712
Content-Type: text/plain; charset=UTF-8

On Monday, January 4, 2016 at 6:10:58 PM UTC-5, Hyman Rosen wrote:
>
> It's no pretense.  The defined order side *is* bright and rosy, while the
> unspecified side *is* Satan's playground.  But as some people like to
> say, the most clever thing Satan ever did is to convince people that he
> doesn't exist.  He's the one whispering "optimization" and "teach people
> not to do that".
>
>
Declaring your opposition to be Satan is not an effective way to win people
to your position. Pro-tip.

Also, stop top-posting.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, January 4, 2016 at 6:10:58 PM UTC-5, Hyman Rose=
n 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">It&#3=
9;s no pretense.=C2=A0 The defined order side <i>is</i> bright and rosy, wh=
ile the unspecified side <i>is</i> Satan&#39;s playground.=C2=A0 But as som=
e people like to say, the most clever thing Satan ever did is to convince p=
eople that he doesn&#39;t exist.=C2=A0 He&#39;s the one whispering &quot;op=
timization&quot; and &quot;teach people not to do that&quot;.</div><br></bl=
ockquote><div><br>Declaring your opposition to be Satan is not an effective=
 way to win people to your position. Pro-tip.<br><br>Also, stop top-posting=
..<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_581_1005519067.1451972196712--
------=_Part_580_1445478483.1451972196712--

.

------=_Part_4408_844609446.1451972545132
Content-Type: multipart/alternative;
 boundary="----=_Part_4409_1411178462.1451972545132"

------=_Part_4409_1411178462.1451972545132
Content-Type: text/plain; charset=UTF-8

On Tuesday, January 5, 2016 at 12:35:26 AM UTC-5, Nicol Bolas wrote:
>
> On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote:
>>
>> On 4 January 2016 at 16:31, Greg Marr <greg...@gmail.com> wrote:
>>
>
>>
>>> This sounds like the
>>> strict aliasing options in gcc/clang.
>>>
>>
>> Which is beyond the purview of the standard.
>>
>
> That hasn't people from writing code that requires those flags.
>
>
"That hasn't *prevented* 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Tuesday, January 5, 2016 at 12:35:26 AM UTC-5, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Monday, January 4, 2016 at 6:05:33=
 PM UTC-5, Nevin &quot;:-)&quot; Liber wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div>On 4 January 2016 at 16:31, Greg Marr <span dir=3D"ltr">&lt;=
<a rel=3D"nofollow">greg...@gmail.com</a>&gt;</span> wrote:</div></blockquo=
te><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"><div><div class=
=3D"gmail_quote"><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(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
This sounds like the</div><div>strict aliasing options in gcc/clang.</div><=
/div></blockquote><div><br></div><div>Which is beyond the purview of the st=
andard.</div></div></div></div></blockquote><div><br>That hasn&#39;t people=
 from writing code that requires those flags.</div><br></blockquote><div><b=
r>&quot;That hasn&#39;t <b>prevented</b> people...&quot; <br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_4409_1411178462.1451972545132--
------=_Part_4408_844609446.1451972545132--

.

------=_Part_739_2096266345.1451986957685
Content-Type: multipart/alternative;
 boundary="----=_Part_740_710324791.1451986957686"

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



=E5=9C=A8 2016=E5=B9=B41=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8A=E5=8D=8811:28:21=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A
>
> On Monday, January 4, 2016 at 9:31:27 PM UTC-5, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B41=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8A=E5=8D=888:45:51=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A
>>>
>>> On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote=
:
>>>>
>>>> A compiler writer could not write a sanitizer to detect order-dependen=
t=20
>>>> code, because deliberate order-dependent code is indistinguishable fro=
m=20
>>>> accidental order-dependent code.
>>>>
>>>
>>> They certainly could do such a thing.  There are lots of things
>>> that compilers and especially code analysis tools such as lint
>>> and the new code checker from MS warn about that are=20
>>> perfectly valid under the standard, such as
>>>
>>> if (i =3D 0)
>>> {
>>> }
>>>
>>> and=20
>>>
>>> Object *o =3D new Object;
>>> =20
>>>
>> They are different, in aspect of semantic equivalence.
>>
>
> In what way?  They're all things that the standard says are perfectly
> legal, but are things that are not recommended as they are difficult
> to get right.
>
>
I have not tried the specific code checker yet. Let me guess the general=20
advice.

'if(i =3D 0)' is suggested to be 'if((i =3D 0))', or 'i =3D 0; if(i =3D=3D =
0)'. They=20
are semantically equivalent.
=20
'Object *o =3D new Object;' is suggested to be something like 'auto o =3D=
=20
std::make_unique<Object>();' or even 'Object o;' in a proper scope. They=20
are semantically different, but may reflect to the same intent with same=20
meaning, and implementation can generate identical code under the as-if=20
rule.

However, adding limitation on evaluation order is different to cases above.=
=20
The worse thing is it may mess up the intention. The checker can suggest=20
nothing precisely since there is no equivalent replacement guaranteed by=20
the language.

In fact, a code checker clever enough is allowed to suggest the inverse=20
transformation (to eliminate unnecessary value dependencies like an=20
optimizer) when current evaluation rules, though I find no implementation=
=20
doing that. It might be not worthy as an optimizing compiler.

If we nail down the order, there is effectively no way to discourage=20
>>>> writing order-dependent code.
>>>>
>>>
>>> Sure there is, see above. We can discourage it the same way we
>>> discourage naked new.
>>>
>>> There is no replacement. You have only diagnostics which can not be=20
>> mandated.
>>
>
> Same as both of the cases above that tools already warn about.  There is =
no
> way to discourage them short of diagnostics that can not be mandated.
> =20
>
Again, they are different. You can suggest one to replace another when they=
=20
have the same meaning. Whether to make the evaluation intentionally=20
order-dependent or not, are not the same.
=20

> To discourage it like "new" - "do not use new if make_unique ... are=20
>> suited"? Then it should be like "do not rely on order-dependent expressi=
on=20
>> evaluation, use statements instead". This requires no change on expressi=
on=20
>> evaluation rules, also much clearer. Why need an additional subopimal wa=
y?
>>
>
> So that there are no portability problems because of non-deterministic
> behavior with the code as written, even if the tool doesn't recognize
> that there is a potential order of evaluation issue.
> =20
>
I suspect this may encourage bug-to-bug compatibility.

If implicit rules are error-prone, provide explicit replacement. Folding=20
different things together and pretending there is no difference will never=
=20
fix it.
=20

> =20
>>
>>> We have a very similar situation with throwing through a noexcept(true)=
=20
>>>> function, as there is no way to distinguish between deliberately doing=
 so=20
>>>> to terminate vs. accidentally doing so to terminate.
>>>>
>>>> I think it is ridiculous to nail down the order and then tell people=
=20
>>>> not to rely on it.  When has that ever worked?
>>>>
>>>
>>> I think it is ridiculous to simply tell people not to rely on any order=
..=20
>>>  We know that doesn't work.
>>>
>>> What do you expect about "work"?
>>
>
> That people follow the advice and don't write code that has
> unspecified behavior.  They do it now because they either ignore
> the advice, or because they don't know that their code has
> unspecified behavior, or both.
>
> I don't think the change would encourage coders willing to learn such=20
advice or rules about unspecified behavior. On the contrast, since some old=
=20
bad code will be portable and guaranteed to work as previously wrong=20
expectation, they might be happy to the status quo, as if there was no=20
change of the rules. Anyway, most of them might not care the rules at all.=
=20
For people who did not know the rules, they would likely keep ignorant in=
=20
future.
=20

> If you are saying to try to make the current code correct, no one will=20
>> work. Wrong code are wrong by not reflecting the original intent clearly=
,=20
>> whatever the change of semantics rules. It is still hard to estimate the=
=20
>> cost of maintenance (if not worse).
>>
>> If you are saying you can expect better code in future ... I am not=20
>> convinced. Most people who would get it wrong will simply not pay attent=
ion=20
>> to it, since it is always (for conforming code) or mostly (for=20
>> dialect-specific code) "non-breaking" to program behavior. I can only=20
>> expect more bugs are hidden.
>>
>
> If the same code always produces the same result under all
> compilers and optimization settings, then the unexpected result
> has a much better chance of being noticed right away, instead of=20
> being silently wrong until the order of evaluation changes, at which
> time the code in question is probably not being actively developed,
> and so may not be tested in such a way as to expose the bug.
>
> The unexpected behavior may be easier or harder to be noticed. It is true=
=20
that the unexpected behavior would be easier to locate. However, since the=
=20
implementation are forced to guarantee more specific behavior, the=20
unexpected behavior itself would probably be limited and less noticeable.=
=20
For example, unsequenced evaluation with side effects on same scalar object=
=20
will lead to undefined behavior, whose unexpectation is allowed being=20
propagated to the whole program, which is generally easier to be noticed=20
with same coverage.

It also makes readers harder to realize the original meaning behind the=20
code. Thus, it effectively lifts the potential coding bugs up to a broader=
=20
range, which will probably make things worse.
=20

> =20
>>
>>> I don't think anyone here disagrees with this.  The question is what do
>>>>> most authors prefer, correctness or performance?  I don't know anyone
>>>>> who would say "I'll take the wrong answer, just give it to me fast."
>>>>>
>>>>
>>>> I want the right answer, as fast as possible, w/o me having to write=
=20
>>>> convoluted / non-portable code because the compiler isn't allowed to=
=20
>>>> optimize my code.  I want unicorns, too. :-)
>>>>
>>>
>>> The important part there being "the right answer".  We're
>>> currently writing non-portable code without even knowing it.
>>>
>> Why are we not knowing it?
>>
> =20
>
>> Why are you here If you are not knowing it?
>>
>
> Because it's not always obvious.  Have you not seen the posts
> in this thread about the code which existed in print for many
> years, read by many language experts, before the order of
> evaluation errors were found?=20
>
> Then you know it. You are not going to write such code in future, are you=
?

Let the ancient code dead. If indeed necessary, they can be work around by=
=20
extensions of dialects. No need to require them being portable even it=20
might be commonly adopted and useful. (Related: why no #pragma once in the=
=20
standard?)


>> If optimizer writers want to make an option that says "assume that all
>>>>> code has no OOE dependencies in it, and act as if the C++14 rules wer=
e
>>>>> still in place" for those authors that write performance critical cod=
e=20
>>>>> where
>>>>> they've already evaluated all of the OOE dependencies, I'd be fine=20
>>>>> with that,
>>>>> as long as the behavior wasn't unspecified by default. =20
>>>>>
>>>>
>>>> That is beyond the purview of the standard.
>>>> =20
>>>>
>>>>> This sounds like the
>>>>> strict aliasing options in gcc/clang.
>>>>>
>>>>
>>>> Which is beyond the purview of the standard.
>>>>
>>>
>>> I didn't say anything about the standard.  I said the
>>> optimizer writers could give the users this option.
>>> =20
>>>
>> Things are different as a standardized language and dialects.
>>
>> You have cared about "non-portable code". How code would be portable=20
>> without normative specification? That is the right place for standard.
>>
>
> Yes, the code is portable.  This is talking about enabling a
> potential future optimization that, when used properly, allows
> the optimizer to make certain assumptions about the code
> that the standard as a whole wouldn't otherwise allow, namely
> reordering operations that in C++14 are unsequenced, but were=20
> later defined to have a given sequence.  I mention this only
> because people are worried that this eliminates the ability of
> a theoretical optimizer to reorder operations in a way that
> provides better performance in cases where the author knows
> that the code is correct under the C++14 rules.  I don't have
> a need for it or see that I would use it in any of my projects.
> =20
>
As I said before, this is not only for theoretical optimization, but=20
expressiveness. The room of such optimization is one consequence of it.

I'm not so strongly against at changing the default rules as long as there=
=20
is replacement provided (by a new proposal), even though I'd rewrite most=
=20
of my code. (However, there are issues concerned with proposed rules.)
=20

>
>> This is also like the difference between the fast and precise floating=
=20
>>>>> point
>>>>> code options in the MS VC++ compiler.  There was a thread about=20
>>>>> possibly
>>>>> changing that default recently, and overwhelmingly users preferred=20
>>>>> precise
>>>>> over fast by default, with the option to change to fast where the=20
>>>>> author had
>>>>> done the necessary analysis and testing to prove that there would be =
no
>>>>> negative effects on correctness.
>>>>>
>>>>
>>>> I'm willing to bet that most people don't understand floating point=20
>>>> well enough to evaluate a decision like that; "precise" just sounds be=
tter=20
>>>> than "fast".  And that is also beyond the purview of the standard.
>>>>
>>>
>>> Exactly, and that is something that is currently done by
>>> compiler writers.
>>> =20
>>>
>>>> I'm not saying we shouldn't make this change, but we should do it base=
d=20
>>>> on data and with our eyes open, instead of pretending one side is brig=
ht=20
>>>> and rosy while the other is satin's playground.
>>>>
>>>
>>> What additional data do you want that can actually be provided?
>>> It's a theoretical optimization that no one has implemented.
>>> How are you planning to measure that?
>>> Do we have to put off fixing this issue until someone implements
>>> this theoretical optimization so that someone can measure it?
>>>
>>> This is not the issue to *fix*. There can be fix (on expresiveness) to=
=20
>> "fix" of this issue, though.
>>
>
> Sorry, I don't understand this sentence.
>
>  I feel that the current rules in the standard are OK, and the proposed=
=20
rules will lead to limitation on semantics, which is a far more serious and=
=20
new issue probably to be fixed in future (by providing replacement to=20
express unordered/nondeterminism evaluation).

Data is basically irrelevant 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2016=E5=B9=B41=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=
=8C UTC+8=E4=B8=8A=E5=8D=8811:28:21=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=
=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, January 4, 20=
16 at 9:31:27 PM UTC-5, FrankHB1989 wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">=E5=9C=A8 2016=E5=B9=B41=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=
=8C UTC+8=E4=B8=8A=E5=8D=888:45:51=EF=BC=8CGreg Marr=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">On Monday, January 4, 2016 at=
 6:05:33 PM UTC-5, Nevin &quot;:-)&quot; Liber wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote">A compiler wr=
iter could not write a sanitizer to detect order-dependent code, because de=
liberate order-dependent code is indistinguishable from accidental order-de=
pendent code.<br></div></div></blockquote><div><br></div><div>They certainl=
y could do such a thing. =C2=A0There are lots of things</div><div>that comp=
ilers and especially code analysis tools such as lint</div><div>and the new=
 code checker from MS warn about that are=C2=A0</div><div>perfectly valid u=
nder the standard, such as</div><div><br></div><div>if (i =3D 0)</div><div>=
{</div><div>}</div><div><br></div><div>and=C2=A0</div><div><br></div><div>O=
bject *o =3D new Object;</div><div>=C2=A0</div></blockquote><div>They are d=
ifferent, in aspect of semantic equivalence.<br></div></blockquote><div><br=
></div><div>In what way? =C2=A0They&#39;re all things that the standard say=
s are perfectly</div><div>legal, but are things that are not recommended as=
 they are difficult</div><div>to get right.</div><div><br></div></blockquot=
e><div><br>I have not tried the specific code checker yet. Let me guess the=
 general advice.<br><br>&#39;if(i =3D 0)&#39; is suggested to be &#39;if((i=
 =3D 0))&#39;, or &#39;i =3D 0; if(i =3D=3D 0)&#39;. They are semantically =
equivalent.<br>=C2=A0<br>&#39;Object *o =3D new Object;&#39; is suggested t=
o be something like &#39;auto o =3D std::make_unique&lt;Object&gt;();&#39; =
or even &#39;Object o;&#39; in a proper scope. They are semantically differ=
ent, but may reflect to the same intent with same meaning, and implementati=
on can generate identical code under the as-if rule.<br><br>However, adding=
 limitation on evaluation order is different to cases above. The worse thin=
g is it may mess up the intention. The checker can suggest nothing precisel=
y since there is no equivalent replacement guaranteed by the language.<br><=
br>In fact, a code checker clever enough is allowed to suggest the inverse =
transformation (to eliminate unnecessary value dependencies like an optimiz=
er) when current evaluation rules, though I find no implementation doing th=
at. It might be not worthy as an optimizing compiler.<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>If we na=
il down the order, there is effectively no way to discourage writing order-=
dependent code.<br></div></div></div></blockquote><div><br></div><div>Sure =
there is, see above. We can discourage it the same way we</div><div>discour=
age naked new.</div><div><br></div></blockquote><div>There is no replacemen=
t. You have only diagnostics which can not be mandated.<br></div></blockquo=
te><div><br></div><div>Same as both of the cases above that tools already w=
arn about. =C2=A0There is no</div><div>way to discourage them short of diag=
nostics that can not be mandated.</div><div>=C2=A0</div></blockquote><div>A=
gain, they are different. You can suggest one to replace another when they =
have the same meaning. Whether to make the evaluation intentionally order-d=
ependent or not, are not the same.<br>=C2=A0<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>To dis=
courage it like &quot;new&quot; - &quot;do not use new if make_unique ... a=
re suited&quot;? Then it should be like &quot;do not rely on order-dependen=
t expression evaluation, use statements instead&quot;. This requires no cha=
nge on expression evaluation rules, also much clearer. Why need an addition=
al subopimal way?<br></div></blockquote><div><br></div><div>So that there a=
re no portability problems because of non-deterministic</div><div>behavior =
with the code as written, even if the tool doesn&#39;t recognize</div><div>=
that there is a potential order of evaluation issue.</div><div>=C2=A0</div>=
</blockquote><div>I suspect this may encourage bug-to-bug compatibility.<br=
><br>If implicit rules are error-prone, provide explicit replacement. Foldi=
ng different things together and pretending there is no difference will nev=
er fix it.<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;">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>=C2=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div></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 class=3D"gmail_quote"><div></div><div>We have a ver=
y similar situation with throwing through a noexcept(true) function, as the=
re is no way to distinguish between deliberately doing so to terminate vs. =
accidentally doing so to terminate.<br></div><div><br></div><div>I think it=
 is ridiculous to nail down the order and then tell people not to rely on i=
t.=C2=A0 When has that ever worked?<br></div></div></div></blockquote><div>=
<br></div><div>I think it is ridiculous to simply tell people not to rely o=
n any order. =C2=A0We know that doesn&#39;t work.</div><div><br></div></blo=
ckquote><div>What do you expect about &quot;work&quot;?<br></div></blockquo=
te><div><br></div><div>That people follow the advice and don&#39;t write co=
de that has</div><div>unspecified behavior. =C2=A0They do it now because th=
ey either ignore</div><div>the advice, or because they don&#39;t know that =
their code has</div><div>unspecified behavior, or both.</div><div><br></div=
></blockquote><div>I don&#39;t think the change would encourage coders will=
ing to learn such advice or rules about unspecified behavior. On the contra=
st, since some old bad code will be portable and guaranteed to work as prev=
iously wrong expectation, they might be happy to the status quo, as if ther=
e was no change of the rules. Anyway, most of them might not care the rules=
 at all. For people who did not know the rules, they would likely keep igno=
rant in future.<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><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>If you are sa=
ying to try to make the current code correct, no one will work. Wrong code =
are wrong by not reflecting the original intent clearly, whatever the chang=
e of semantics rules. It is still hard to estimate the cost of maintenance =
(if not worse).<br><br>If you are saying you can expect better code in futu=
re ... I am not convinced. Most people who would get it wrong will simply n=
ot pay attention to it, since it is always (for conforming code) or mostly =
(for dialect-specific code) &quot;non-breaking&quot; to program behavior. I=
 can only expect more bugs are hidden.<br></div></blockquote><div><br></div=
><div>If the same code always produces the same result under all</div><div>=
compilers and optimization settings, then the unexpected result</div><div>h=
as a much better chance of being noticed right away, instead of=C2=A0</div>=
<div>being silently wrong until the order of evaluation changes, at which</=
div><div>time the code in question is probably not being actively developed=
,</div><div>and so may not be tested in such a way as to expose the bug.</d=
iv><div><br></div></blockquote><div>The unexpected behavior may be easier o=
r harder to be noticed. It is true that the unexpected behavior would be ea=
sier to locate. However, since the implementation are forced to guarantee m=
ore specific behavior, the unexpected behavior itself would probably be lim=
ited and less noticeable. For example, unsequenced evaluation with side eff=
ects on same scalar object will lead to undefined behavior, whose unexpecta=
tion is allowed being propagated to the whole program, which is generally e=
asier to be noticed with same coverage.<br><br>It also makes readers harder=
 to realize the original meaning behind the code. Thus, it effectively lift=
s the potential coding bugs up to a broader range, which will probably make=
 things worse.<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><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>=C2=A0<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><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 class=3D"gmail_quote"><div></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&#39;t think anyone here disagre=
es with this.=C2=A0 The question is what do<br></div><div>most authors pref=
er, correctness or performance?=C2=A0 I don&#39;t know anyone</div><div>who=
 would say &quot;I&#39;ll take the wrong answer, just give it to me fast.&q=
uot;</div></div></blockquote><div><br></div><div>I want the right answer, a=
s fast as possible, w/o me having to write convoluted / non-portable code b=
ecause the compiler isn&#39;t allowed to optimize my code.=C2=A0 I want uni=
corns, too. :-)</div></div></div></blockquote><div><br></div><div>The impor=
tant part there being &quot;the right answer&quot;. =C2=A0We&#39;re</div><d=
iv>currently writing non-portable code without even knowing it.</div></bloc=
kquote><div>Why are we not knowing it?<br></div></blockquote><div>=C2=A0<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div>Why are you here If you=
 are not knowing it?<br></div></blockquote><div><br></div><div>Because it&#=
39;s not always obvious. =C2=A0Have you not seen the posts</div><div>in thi=
s thread about the code which existed in print for many</div><div>years, re=
ad by many language experts, before the order of</div><div>evaluation error=
s were found?=C2=A0</div><div><br></div></blockquote><div>Then you know it.=
 You are not going to write such code in future, are you?<br><br>Let the an=
cient code dead. If indeed necessary, they can be work around by extensions=
 of dialects. No need to require them being portable even it might be commo=
nly adopted and useful. (Related: why no #pragma once in the standard?)<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></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><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 cl=
ass=3D"gmail_quote"><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"><div>If optimizer wri=
ters want to make an option that says &quot;assume that all<br></div><div>c=
ode has no OOE dependencies in it, and act as if the C++14 rules were</div>=
<div>still in place&quot; for those authors that write performance critical=
 code where</div><div>they&#39;ve already evaluated all of the OOE dependen=
cies, I&#39;d be fine with that,</div><div>as long as the behavior wasn&#39=
;t unspecified by default. =C2=A0</div></div></blockquote><div><br></div><d=
iv>That is beyond the purview of the standard.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div dir=3D"ltr"><div>This sounds like the</div><div>strict alia=
sing options in gcc/clang.</div></div></blockquote><div><br></div><div>Whic=
h is beyond the purview of the standard.</div></div></div></blockquote><div=
><br></div><div>I didn&#39;t say anything about the standard. =C2=A0I said =
the</div><div>optimizer writers could give the users this option.</div><div=
>=C2=A0<br></div></blockquote><div>Things are different as a standardized l=
anguage and dialects.<br><br>You have cared about &quot;non-portable code&q=
uot;. How code would be portable without normative specification? That is t=
he right place for standard.<br></div></blockquote><div><br></div><div>Yes,=
 the code is portable. =C2=A0This is talking about enabling a</div><div>pot=
ential future optimization that, when used properly, allows</div><div>the o=
ptimizer to make certain assumptions about the code</div><div>that the stan=
dard as a whole wouldn&#39;t otherwise allow, namely</div><div>reordering o=
perations that in C++14 are unsequenced, but were=C2=A0</div><div>later def=
ined to have a given sequence. =C2=A0I mention this only</div><div>because =
people are worried that this eliminates the ability of</div><div>a theoreti=
cal optimizer to reorder operations in a way that</div><div>provides better=
 performance in cases where the author knows</div><div>that the code is cor=
rect under the C++14 rules. =C2=A0I don&#39;t have</div><div>a need for it =
or see that I would use it in any of my projects.</div><div>=C2=A0<br></div=
></blockquote><div>As I said before, this is not only for theoretical optim=
ization, but expressiveness. The room of such optimization is one consequen=
ce of it.<br><br>I&#39;m not so strongly against at changing the default ru=
les as long as there is replacement provided (by a new proposal), even thou=
gh I&#39;d rewrite most of my code. (However, there are issues concerned wi=
th proposed rules.)<br>=C2=A0<br></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></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><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 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-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>This is also like the difference between=
 the fast and precise floating point<br></div><div>code options in the MS V=
C++ compiler.=C2=A0 There was a thread about possibly</div><div>changing th=
at default recently, and overwhelmingly users preferred precise</div><div>o=
ver fast by default, with the option to change to fast where the author had=
</div><div>done the necessary analysis and testing to prove that there woul=
d be no</div><div>negative effects on correctness.</div></div></blockquote>=
<div><br></div><div>I&#39;m willing to bet that most people don&#39;t under=
stand floating point well enough to evaluate a decision like that; &quot;pr=
ecise&quot; just sounds better than &quot;fast&quot;.=C2=A0 And that is als=
o beyond the purview of the standard.</div></div></div></blockquote><div><b=
r></div><div>Exactly, and that is something that is currently done by</div>=
<div>compiler writers.</div><div>=C2=A0</div><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 class=3D"gmail_quote"><div>I&#39;m not sayi=
ng we shouldn&#39;t make this change, but we should do it based on data and=
 with our eyes open, instead of pretending one side is bright and rosy whil=
e the other is satin&#39;s playground.<br></div></div></div></blockquote><d=
iv><br></div><div>What additional data do you want that can actually be pro=
vided?</div><div>It&#39;s a theoretical optimization that no one has implem=
ented.</div><div>How are you planning to measure that?</div><div>Do we have=
 to put off fixing this issue until someone implements</div><div>this theor=
etical optimization so that someone can measure it?</div><div><br></div></b=
lockquote><div>This is not the issue to <i>fix</i>. There can be fix (on ex=
presiveness) to &quot;fix&quot; of this issue, though.<br></div></blockquot=
e><div><br></div><div>Sorry, I don&#39;t understand this sentence.</div><di=
v><br></div></blockquote><div>=C2=A0I feel that the current rules in the st=
andard are OK, and the proposed rules will lead to limitation on semantics,=
 which is a far more serious and new issue probably to be fixed in future (=
by providing replacement to express unordered/nondeterminism evaluation).<b=
r><br>Data is basically irrelevant here.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_740_710324791.1451986957686--
------=_Part_739_2096266345.1451986957685--

.

On 2016-01-04 17:31, Greg Marr wrote:
> On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:
>> There's "correctness" and there's "correctness". Right now, there is
>> widespread discouragement against writing order-sensitive code in the
>> first place (in the sense of 'OOE will affect the result'). Thus, the
>> starting assumption is that the code "works", regardless of OOE.
>
> I want to be sure I understand what you mean.  I see two possible
> interpretations here:
>
> 1. Because of all the discouragement against writing order-sensitive
> code, we should assume that all code that has ever been written
> works regardless of OOE because everyone knows not to rely on it,
> and can recognize and avoid all OOE errors.

That's... stronger than I would put it. There is still room here for
e.g. sanitizers. The point is more that a) there is debate over just how
badly broken things really are in this area, and b) there exists much
code that is correct *even though OOE is unspecified*.

> 2. The particular bit of code that is discussed next works regardless
> of OOE because the author knows not to rely on it and has done
> the necessary research to determine that the code is okay,

Again, that's a little strong. I would say it works regardless of OOE
because the API is well designed and free of surprising side effects.
That is, I believe that *MUCH* more code is written that "just happens
to work" regardless of OOE than runs afoul of OOE.

The examples I've seen of where OOE is a problem just *look* ugly (e.g.
'a[i++] = ++i - ++i'). Much more code contains multiple subexpressions
where the order *just doesn't matter*. I doubt very much that every time
such code is written, the author is specifically considering OOE.

> so we're going to assume for the purpose of this optimization
> discussion that it is free of OOE errors.

Sure.

>> Or, to put it more succinctly, defined ordering severely restricts CSE
>> compared to the current situation.
>
> I don't think anyone here disagrees with this.  The question is what do
> most authors prefer, correctness or performance?

Again, I think this overstates the case. You're presenting the question
as black and white, when reality is somewhere in between. There is a
cost to errors due to unspecified OOE. There is also a cost to lost
optimization due to forcing a particular OOE unnecessarily. A fair
assessment cannot be given without considering the *values* of those
costs (even if one is weighted more heavily).

For instance, I don't think we would be having this discussion if the
performance cost made 80% of all code take twice as long to execute
while there exists a single, contrived example of where someone *might*
be bitten by unspecified OOE. Obviously, I am exaggerating for effect,
but the point is that a) it isn't just black-and-white, and b) my own
perception of the relative costs does not match what I perceive as
others implying those costs to be.

(And yes, I'm well aware that the response to that is going to be
"Stockholm Syndrome".)

And, as I've stated previously, part of why I'm arguing is as much
because I feel like there needs to be *someone* arguing against, just
for the sake of having a complete understanding of the potential
drawbacks, because there is an impression that this hasn't been taking
place.

> If optimizer writers want to make an option that says "assume that all
> code has no OOE dependencies in it, and act as if the C++14 rules were
> still in place" for those authors that write performance critical code where
> they've already evaluated all of the OOE dependencies, I'd be fine with
> that,

Yes, at the least I rather expect compilers to develop a
-funspecified-order (or similar) option if C++17 has defined OOE.

What makes such flags difficult, of course, is that it's hard to employ
them on a fine-grained basis.

FWIW, the potential performance impact would be substantially mitigated
if we had standard ways to annotate what side effects are permitted. One
problem is that right now we lack standard tools to assist the compiler
with as-if evaluation. If we had those (even better, if we'd had them
for some years and they were as widely employed as 'const'), we probably
wouldn't be having this conversation.

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-01-04 18:04, Nevin Liber wrote:
> Fixing the order will definitely break code that is accidentally dependent
> on the current order.  It doesn't magically make currently broken code
> correct, unless you happen to pick the same order.

For the sake of fairness, this *also* smells like a straw man. Such code
is already broken. We usually have not given much weight to breaking
code that relies on a particular flavor of unspecified (or undefined)
behavior, as such code is not standard-conforming.

> A compiler writer could not write a sanitizer to detect order-dependent
> code, because deliberate order-dependent code is indistinguishable from
> accidental order-dependent code.
>
> Heck, a conforming compiler couldn't refuse to compile order-dependent code
> for the same reason.

I'm not sure this is true; compilers / sanitizers already flag certain
constructs that are standard-conforming but may be considered dangerous.

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 5 January 2016 at 16:29, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> And, as I've stated previously, part of why I'm arguing is as much
> because I feel like there needs to be *someone* arguing against, just
> for the sake of having a complete understanding of the potential
> drawbacks, because there is an impression that this hasn't been taking
> place.


That's certainly an interesting impression. I, however, am under the impression
that if such arguing hadn't taken place, defined expression evaluation order
would be much further along than it currently is, which is that it's still under
refinement and review in the committee.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 5 January 2016 at 16:38, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> Heck, a conforming compiler couldn't refuse to compile order-dependent code
>> for the same reason.
> I'm not sure this is true; compilers / sanitizers already flag certain
> constructs that are standard-conforming but may be considered dangerous.

Well, there's a difference between what a conforming compiler can do and what
an implementation that chooses to reject conforming code can 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-01-05 09:43, Ville Voutilainen wrote:
> On 5 January 2016 at 16:38, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>> Heck, a conforming compiler couldn't refuse to compile order-dependent code
>>> for the same reason.
>> I'm not sure this is true; compilers / sanitizers already flag certain
>> constructs that are standard-conforming but may be considered dangerous.
>
> Well, there's a difference between what a conforming compiler can do and what
> an implementation that chooses to reject conforming code can do. ;)

Er... right. Sorry, that was poorly worded.

A relevant -Werror would indeed be technically non-conforming. (As is
-Werror in general.)

(Also, my previous comment was mainly aimed at the first point, which
you snipped, i.e. the "could not write a sanitizer" point. And certainly
a *non*-fatal diagnostic can also be implemented and would still be
conforming.)

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-01-04 19:45, Greg Marr wrote:
> On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote:
>> What is the impact of doing so?  I've yet to see anyone quantify it,=20
>> produce a reasonable benchmark, etc.
>=20
> The impact of not doing an optimization that no one currently does?

Well... yes :-). That's one of the major problems; we *can't* (readily)
quantify the cost, because it's a cost in potential, not a cost that
directly affects actual current practice. (And, no, I don't agree with
Nicol that potential costs / potential benefits are irrelevant.)

This is true for both directions; part=C2=B9 of the purported benefit is in
relieving programmers from having to think about (or, more importantly,
be taught about=C2=B2) OOE issues.

(=C2=B9 Please note that I said *"part"*. I'm well aware there is also
currently measurable cost in bugs due to OOE issues.)

(=C2=B2 I would say I am not *consciously* aware of OOE issues, but simply =
in
the habit of avoiding them. Maybe even "on principle". This, as was
mentioned elsewhere, is also an important point; if we continue to avoid
OOE-dependent code for other reasons, the alleged benefit in not having
to teach new programmers about it is significantly reduced.)

>> If we nail down the order, there is effectively no way to discourage=20
>> writing order-dependent code.
>=20
> Sure there is, see above. We can discourage it the same way we
> discourage naked new.

....in which case, as above, much of the benefit evaporates, thereby
significantly weakening the argument in favor of defined OOE.

> I think it is ridiculous to simply tell people not to rely on any order.=
=20
>  We know that doesn't work.

....and yet, this contradicts your previous comment.

> if (i =3D 0)
> {
> }

OT, but this exact example is *almost* certainly an error, especially in
production code, because the conditional is non-trivial but still is
always false. It *is* technically conforming, but I would hope that all
compilers warn about it by default. ('if (x =3D y)' would be a better
example; I can readily imagine this code being correct, while it's much
harder to imagine the above ever being correct.)

On 2016-01-04 22:28, Greg Marr wrote:
> Have you not seen the posts in this thread about the code which
> existed in print for many years, read by many language experts,
> before the order of evaluation errors were found?

I actually can't say that I have. I *think* I've read the entire thread,
but considering the length, you might want to point them out again.

--=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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

On 5 January 2016 at 17:04, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> Well, there's a difference between what a conforming compiler can do and what
>> an implementation that chooses to reject conforming code can do. ;)
> Er... right. Sorry, that was poorly worded.
> A relevant -Werror would indeed be technically non-conforming. (As is
> -Werror in general.)

I don't know what that's supposed to mean.

> (Also, my previous comment was mainly aimed at the first point, which
> you snipped, i.e. the "could not write a sanitizer" point. And certainly
> a *non*-fatal diagnostic can also be implemented and would still be
> conforming.)

What does the "*non*" matter? Regardless of that question and the remark
above, whether diagnostics and/or sanitizers are conforming in what they reject
has done fairly little to stop them before, although in some cases
what sanitizers
can really do based on their own design is affected (an UB sanitizer
cannot diagnose
things which aren't UB, duh). That probably wouldn't be the case here;
if someone
wants to write an OOE sanitizer, the usefulness and capability of such
a sanitizer
doesn't vanish overnight even if C++17 chooses to define the evaluation order,
as such a sanitizer could still flag (back-)portability issues.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-01-05 10:22, Ville Voutilainen wrote:
> On 5 January 2016 at 17:04, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> A relevant -Werror would indeed be technically non-conforming. (As is
>> -Werror in general.)
>
> I don't know what that's supposed to mean.

See also Nicol's reply. Most (if not all) uses of -Werror are
non-conforming. (I may be confusing you due to misreading your previous
comment, however.)

>> ([...]certainly a *non*-fatal diagnostic can also be implemented
>> and would still be conforming.)
>
> What does the "*non*" matter?

A conforming compiler is allowed to print text to stdout / stderr, in
addition to generating an object file, yes?

> Regardless of that question and the remark above, whether diagnostics
> and/or sanitizers are conforming in what they reject has done fairly
> little to stop them before

Er... right. Maybe we are in violent agreement? ;-) (In fact, looking
again, I may have misread your previous comment and we've been violently
agreeing for several messages now. Apologies :-).)

> if someone wants to write an OOE sanitizer, the usefulness and
> capability of such a sanitizer doesn't vanish overnight even if C++17
> chooses to define the evaluation order, as such a sanitizer could
> still flag (back-)portability issues.

....or it could flag issues just because people don't like OOE-dependent
code, same as flagging use of naked 'new', -Weff-c++ items, or any of a
slew of other things that are perfectly valid but still considered poor
style :-).

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 5 January 2016 at 17:44, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2016-01-05 10:22, Ville Voutilainen wrote:
>> On 5 January 2016 at 17:04, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>> A relevant -Werror would indeed be technically non-conforming. (As is
>>> -Werror in general.)
>>
>> I don't know what that's supposed to mean.
>
> See also Nicol's reply. Most (if not all) uses of -Werror are
> non-conforming. (I may be confusing you due to misreading your previous
> comment, however.)

Which reply? I don't recognize the claim that uses of -Werror are non-conforming
to be correct.

>>> ([...]certainly a *non*-fatal diagnostic can also be implemented
>>> and would still be conforming.)
>> What does the "*non*" matter?
> A conforming compiler is allowed to print text to stdout / stderr, in
> addition to generating an object file, yes?

Sure, as far as I understand the vague wording the standard has about
"diagnostics".

>> Regardless of that question and the remark above, whether diagnostics
>> and/or sanitizers are conforming in what they reject has done fairly
>> little to stop them before
> Er... right. Maybe we are in violent agreement? ;-) (In fact, looking
> again, I may have misread your previous comment and we've been violently
> agreeing for several messages now. Apologies :-).)

No worries. The point is that I don't think whether diagnostics are or are
not conforming is a major practical hindrance for implementations to
provide diagnostics. ;)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-01-05 10:50, Ville Voutilainen wrote:
> On 5 January 2016 at 17:44, Matthew Woehlke wrote:
>> On 2016-01-05 10:22, Ville Voutilainen wrote:
>>> On 5 January 2016 at 17:04, Matthew Woehlke wrote:
>>>> A relevant -Werror would indeed be technically non-conforming. (As is
>>>> -Werror in general.)
>>>
>>> I don't know what that's supposed to mean.
>>
>> See also Nicol's reply. Most (if not all) uses of -Werror are
>> non-conforming. (I may be confusing you due to misreading your previous
>> comment, however.)
>
> Which reply?

http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/23470

> I don't recognize the claim that uses of -Werror are non-conforming
> to be correct.

Aren't they? If a compiler rejects standard-conforming code that "looks
suspicious" (e.g. 'if (i = 0)' to reuse a previous example), isn't that
(at least pedantically) non-conforming?

>>>> ([...]certainly a *non*-fatal diagnostic can also be implemented
>>>> and would still be conforming.)
>>>
>>> What does the "*non*" matter?
>>
>> A conforming compiler is allowed to print text to stdout / stderr, in
>> addition to generating an object file, yes?
>
> Sure, as far as I understand the vague wording the standard has about
> "diagnostics".

:-)

So if the compiler prints a message (warning) but compiles the code
anyway, that's still conforming. That's why the "non" matters; the "non"
is the difference between accepting (with loud noises) the code and
rejecting it. (See also above comments re: -Werror.)

This assumes that you consider rejecting conforming code due to use of
-Werror to be non-conforming, so that may be the source of the confusion.

That said...

> The point is that I don't think whether diagnostics are or are
> not conforming is a major practical hindrance for implementations to
> provide diagnostics. ;)

Oh, sure, we definitely agree on that point :-). The rest of this
conversation can probably be safely ignored as nitpicking :-).

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 5 January 2016 at 18:03, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>> See also Nicol's reply. Most (if not all) uses of -Werror are
>>> non-conforming. (I may be confusing you due to misreading your previous
>>> comment, however.)
>> Which reply?
> http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/23470
>> I don't recognize the claim that uses of -Werror are non-conforming
>> to be correct.
> Aren't they? If a compiler rejects standard-conforming code that "looks
> suspicious" (e.g. 'if (i = 0)' to reuse a previous example), isn't that
> (at least pedantically) non-conforming?

Oh, well, that might be, but there are cases of -Werror where the only
diagnostic
(even for per-standard ill-formed code) a compiler will emit is a
"warning" anyway,
and -Werror just turns that "warning" into an "error" and the standard
couldn't care
less which is which. ;)

> So if the compiler prints a message (warning) but compiles the code
> anyway, that's still conforming. That's why the "non" matters; the "non"

An implementation is allowed to run an ill-formed program if it wants, as
far as I understand the standardese. Apparently any results of doing so
are completely UB but what have you. :P At any rate, the standard doesn't
really state "must not compile", there's very little of that in the spec, mostly
in how #error is specified, although even that is occasionally under some
dispute...

>> The point is that I don't think whether diagnostics are or are
>> not conforming is a major practical hindrance for implementations to
>> provide diagnostics. ;)
> Oh, sure, we definitely agree on that point :-). The rest of this
> conversation can probably be safely ignored as nitpicking :-).

I tend to agree. :)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Tue, Jan 5, 2016 at 12:36 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, January 4, 2016 at 6:10:58 PM UTC-5, Hyman Rosen wrote:
>>
>> It's no pretense.  The defined order side *is* bright and rosy, while
>> the unspecified side *is* Satan's playground.  But as some people like
>> to say, the most clever thing Satan ever did is to convince people that he
>> doesn't exist.  He's the one whispering "optimization" and "teach people
>> not to do that".
>>
>>
> Declaring your opposition to be Satan is not an effective way to win
> people to your position. Pro-tip.
>

This is probably by far the silliest take away in this entire thread. I
don't speak for Hyman but I think the parallel he wants to draw is how
people obsess over the loss of perceived optimizations when no evidence has
been provided as to whether these optimizations even *exist*. You yourself
has argued this point many times else thread.

Also, I don't know if you are aware but this order of evaluation issue has
been argued about a zillion times already when c.l.c++.m and c.s.c++ used
to entertain heavy traffic, nearly 10 years ago. Nothing in this thread is
breaking any new ground. Its the same arguments that have been beaten to
death again & again & again. The only reason we see a resurrection is
because of this proposal and even the authors themselves don't make the
optimization argument against the value of a single defined order of
evaluation (believe me, we have discussed this issue with them).



>
> Also, stop top-posting.
>
>
What if you want to make a general point and not trying to address any
issue in particular?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11401eba0d17480528987e4f
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, Jan 5, 2016 at 12:36 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</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"><span class=
=3D"">On Monday, January 4, 2016 at 6:10:58 PM UTC-5, Hyman Rosen wrote:<bl=
ockquote 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">It&#39;s no pretense.=
=C2=A0 The defined order side <i>is</i> bright and rosy, while the unspecif=
ied side <i>is</i> Satan&#39;s playground.=C2=A0 But as some people like to=
 say, the most clever thing Satan ever did is to convince people that he do=
esn&#39;t exist.=C2=A0 He&#39;s the one whispering &quot;optimization&quot;=
 and &quot;teach people not to do that&quot;.</div><br></blockquote></span>=
<div><br>Declaring your opposition to be Satan is not an effective way to w=
in people to your position. Pro-tip.<br></div></div></blockquote><div><br><=
/div><div>This is probably by far the silliest take away in this entire thr=
ead. I don&#39;t speak for Hyman but I think the parallel he wants to draw =
is how people obsess over the loss of perceived optimizations when no evide=
nce has been provided as to whether these optimizations even *exist*. You y=
ourself has argued this point many times else thread.</div><div><br></div><=
div>Also, I don&#39;t know if you are aware but this order of evaluation is=
sue has been argued about a zillion times already when c.l.c++.m and c.s.c+=
+ used to entertain heavy traffic, nearly 10 years ago. Nothing in this thr=
ead is breaking any new ground. Its the same arguments that have been beate=
n to death again &amp; again &amp; again. The only reason we see a resurrec=
tion is because of this proposal and even the authors themselves don&#39;t =
make the optimization argument against the value of a single defined order =
of evaluation (believe me, we have discussed this issue with them).</div><d=
iv><br></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><br>Also, stop top-posting.<br></div></div><div class=3D"HOEn=
Zb"><div class=3D"h5">

<p></p></div></div></blockquote></div><br></div><div class=3D"gmail_extra">=
What if you want to make a general point and not trying to address any issu=
e in particular?</div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a11401eba0d17480528987e4f--

.

On 5 January 2016 at 18:11, Dilip Ranganathan <misc.usage@gmail.com> wrote:
> Also, I don't know if you are aware but this order of evaluation issue has
> been argued about a zillion times already when c.l.c++.m and c.s.c++ used to
> entertain heavy traffic, nearly 10 years ago. Nothing in this thread is
> breaking any new ground. Its the same arguments that have been beaten to
> death again & again & again. The only reason we see a resurrection is
> because of this proposal and even the authors themselves don't make the
> optimization argument against the value of a single defined order of
> evaluation (believe me, we have discussed this issue with them).

Well, the authors have been asked to provide clearer motivation why
the optimization
arguments are less significant, and have also been asked to provide
clearer motivation
why function call argument ordering is (close to) as important than
defined evaluation
order for other expressions.

There's been some back-and-forth between EWG and CWG on this paper. It's no
trivial matter, so it's no surprise that it draws debate, even among
people who think
"arguments have been beaten to death". This particular proposal is certainly
in the realm of "can't please everybody", but luckily it doesn't need to please
everybody.

>> Also, stop top-posting.
> What if you want to make a general point and not trying to address any issue
> in particular?

Then don't quote anything, either above or below?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Tue, Jan 5, 2016 at 11:20 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> Then don't quote anything, either above or below?


GMail's web interface encourages top-posting; using "reply" quotes the
original message
but hides it under a tiny clickable "..." box and positions the typing
cursor above it.  I think
the reason is that it expects that you're reading in an interface that is
presenting a stream
of posts, so you can see the previous message above the reply, and
therefore don't need
the previous message visibly repeated in the reply.

I'll try to remember not to top-post, for the benefit of people who are
reading differently.

On Tue, Jan 5, 2016 at 12:36 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> Declaring your opposition to be Satan is not an effective way to win
> people to your position. Pro-tip.
>

But there seems to be no such ban on declaring that code which may, or
would like to,
depend on evaluation order to be "bad", and claiming that people who write
such code
should be "banned from working on production code", and so forth.  Plenty
of people
seem ready to make such value judgements about other programmers.

The proposal for specifying some, but not all, order of evaluation has the
good intention
of trying to satisfy both sides of the debate.  We know where good
intentions are said to
lead.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1143fae0f34dd305289983f0
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, Jan 5, 2016 at 11:20 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<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">Then don&#39;t quote anyt=
hing, either above or below?</blockquote><div><br>GMail&#39;s web interface=
 encourages top-posting; using &quot;reply&quot; quotes the original messag=
e<br>but hides it under a tiny clickable &quot;...&quot; box and positions =
the typing cursor above it.=C2=A0 I think<br>the reason is that it expects =
that you&#39;re reading in an interface that is presenting a stream<br>of p=
osts, so you can see the previous message above the reply, and therefore do=
n&#39;t need<br>the previous message visibly repeated in the reply.<br><br>=
I&#39;ll try to remember not to top-post, for the benefit of people who are=
 reading differently.<br><br>On Tue, Jan 5, 2016 at 12:36 AM, Nicol Bolas=
=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div>Declaring your opposition to be Satan is not an effec=
tive way to win people to your position. Pro-tip.</div></div></blockquote><=
div><br>But there seems to be no such ban on declaring that code which may,=
 or would like to,<br>depend=C2=A0on evaluation order to be &quot;bad&quot;=
, and claiming that people who write such code<br>should be=C2=A0&quot;bann=
ed from working on production code&quot;, and so forth.=C2=A0 Plenty of peo=
ple<br>seem ready to=C2=A0make such value judgements about other programmer=
s.<br><br>The proposal for specifying some, but not all, order of evaluatio=
n has the good intention<br>of trying to satisfy both sides of the debate.=
=C2=A0 We know where good intentions are said to<br>lead.</div></div></div>=
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1143fae0f34dd305289983f0--

.

On 2016/01/05 14:35 +0900, Nicol Bolas wrote:
> On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote:
....
>> What is the impact of doing so?  I've yet to see anyone quantify it,
>> produce a reasonable benchmark, etc.
>
> No, we have quantified it. The impact is, as far as we have determined...
> zero.
>
> We have actual evidence in hand that many widely used compilers do not make
> such optimizations. As such, the impact of such a change on those compilers
> will be nothing.
>
> "In the future" is not "today". It's not "now". There is no way to quantify
> what *could happen* in the future. Why should we prepare for some future
> that may never happen, when we can instead deal with problems we already
> have?

I'm feeling odd seeing that you (and a few others in this thread) seem
declaring that there is *no* optimization based on unspecified OOE at
present.

I think I did show an example of such optimization (CSE) in the
precedent thread about function arguments.
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/erAvgOwIBQAJ
> I got an evidence that GCC (5.2, and also 4.4) actually does this kind
> of transformation with "int pure(int) __attribute__((const))".
>   https://goo.gl/AYYOkj
This also applicable to other expressions.

Could you please explain how did you conclude that the impact of
inhibiting these optimization is "zero", while an evidence of non-zero
effect is provided?

--
k_satoda

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-01-05 12:26, Kazutoshi Satoda wrote:
> I'm feeling odd seeing that you (and a few others in this thread) seem
> declaring that there is *no* optimization based on unspecified OOE at
> present.
>=20
> I think I did show an example of such optimization (CSE) in the
> precedent thread about function arguments.
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/er=
AvgOwIBQAJ
>> I got an evidence that GCC (5.2, and also 4.4) actually does this kind
>> of transformation with "int pure(int) __attribute__((const))".
>>   https://goo.gl/AYYOkj
>
> This also applicable to other expressions.
>=20
> Could you please explain how did you conclude that the impact of
> inhibiting these optimization is "zero", while an evidence of non-zero
> effect is provided?

Continuing with my "arguing both sides" hat on=C2=B9, note that once you
start throwing e.g. __attribute__((const)) into the mix, you're giving
the compiler the tools it needs to *prove* when CSE is safe. When it has
those, it can reorder things even if OOE *is* defined, under the as-if
rule(s).

(You may recall I mentioned previously that if these tools were a)
standardized, and b) widely used, it would significantly mitigate the
"lost optimization potential" complaints.)

(=C2=B9 As I've stated on various occasions, while I *am* arguing partly
because I *do* have an opinion on the matter, I'm also arguing for the
sake of seeing the matter thoroughly and fairly explored. In that
capacity, I'm happy to make points for both sides :-).)

--=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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

On 2016/01/06 2:46 +0900, Matthew Woehlke wrote:
> On 2016-01-05 12:26, Kazutoshi Satoda wrote:
....
>> I think I did show an example of such optimization (CSE) in the
>> precedent thread about function arguments.
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/e=
rAvgOwIBQAJ
>>> I got an evidence that GCC (5.2, and also 4.4) actually does this kind
>>> of transformation with "int pure(int) __attribute__((const))".
>>>   https://goo.gl/AYYOkj
>> This also applicable to other expressions.
>>=20
>> Could you please explain how did you conclude that the impact of
>> inhibiting these optimization is "zero", while an evidence of non-zero
>> effect is provided?
>=20
> Continuing with my "arguing both sides" hat on=C2=B9, note that once you
> start throwing e.g. __attribute__((const)) into the mix, you're giving
> the compiler the tools it needs to *prove* when CSE is safe. When it has
> those, it can reorder things even if OOE *is* defined, under the as-if
> rule(s).

You seem missing the effect of intervening call to unknown() in the
example, just like Nicol (and also Gaby?) missed.
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/jGby=
hCvkBQAJ
> You seem missing the point of the example where the function pure() is
....

Also, the existence of the effect can be shown without the attribute and
the calls of pure().

Even if all "pure(non_local)" in the example are replaced to
"non_local", the unspecified OOE still in effect such that the load from
memory (non_local) can be collapsed into once instead of twice.

I employed pure() to show that the effect can be magnified arbitrary
without upper limit.

--=20
k_satoda

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

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

On Tue, Jan 5, 2016 at 1:03 PM, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
wrote:
>
> Even if all "pure(non_local)" in the example are replaced to
> "non_local", the unspecified OOE still in effect such that the load from
> memory (non_local) can be collapsed into once instead of twice.


Given the code
    int x(int);
    struct S { int m; S(); int f() { return x(m - m % 2) + (m - m % 2); } }
s;
    int main(int c, char **v) { return s.f(); }
on x86 both gcc and clang recompute the m - m % 2 subexpression after x
returns,even with -O6/-O3 specified.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1143fae0304aaf05289ae260
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, Jan 5, 2016 at 1:03 PM, Kazutoshi Satoda <span dir=3D"ltr">&lt;<a href=
=3D"mailto:k_satoda@f2.dion.ne.jp" target=3D"_blank">k_satoda@f2.dion.ne.jp=
</a>&gt;</span> 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">
Even if all &quot;pure(non_local)&quot; in the example are replaced to<br>
&quot;non_local&quot;, the unspecified OOE still in effect such that the lo=
ad from<br>
memory (non_local) can be collapsed into once instead of twice.</blockquote=
><div><br>Given the code<font face=3D"monospace, monospace"><br></font><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 int x(int);</font></div>=
<div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 struct S { int m; S(=
); int f() { return x(m - m % 2) + (m - m % 2); } } s;</font></div><div><fo=
nt face=3D"monospace, monospace">=C2=A0 =C2=A0 int main(int c, char **v) { =
return s.f(); }</font><br>on x86 both gcc and clang recompute the m - m % 2=
 subexpression after x returns,even with -O6/-O3 specified.</div></div></di=
v></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1143fae0304aaf05289ae260--

.

------=_Part_9177_343482577.1452021714242
Content-Type: multipart/alternative;
 boundary="----=_Part_9178_64292949.1452021714243"

------=_Part_9178_64292949.1452021714243
Content-Type: text/plain; charset=UTF-8

On Tuesday, 5 January 2016 00:45:51 UTC, Greg Marr wrote:
>
> I don't think anyone here disagrees with this.  The question is what do
>>> most authors prefer, correctness or performance?  I don't know anyone
>>> who would say "I'll take the wrong answer, just give it to me fast."
>>>
>>
>> I want the right answer, as fast as possible, w/o me having to write
>> convoluted / non-portable code because the compiler isn't allowed to
>> optimize my code.  I want unicorns, too. :-)
>>
>
> The important part there being "the right answer".  We're
> currently writing non-portable code without even knowing it.
>

Are we? How often in practice does one (a) create an impure value-returning
function and (b) use it in a non-sequenced expression?


> This sounds like the
>>>
>> strict aliasing options in gcc/clang.
>>>
>>
>> Which is beyond the purview of the standard.
>>
>
> I didn't say anything about the standard.  I said the
> optimizer writers could give the users this option.
>

Turning on strict aliasing still gives a conformant compiler. If you change
the standard to disallow evaluation reordering, then such an option would
make the compiler nonconformant when it is turned on.

If there were demand from users to allow order-dependent code, gcc would
have an option (as -fno-strict-aliasing)
to disallow evaluation reordering. It doesn't, apart from -O0.

Also, perhaps OT, but optimizations aren't the only program transformation
that would be impeded by disallowing evaluation reordering. Changing the
order of function parameters is a common occurrence during API evolution or
substitution, certainly common enough that both Visual Assist and ReSharper
have it as a builtin task. Would you make that illegal?

>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Tuesday, 5 January 2016 00:45:51 UTC, Greg Marr  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_quote"><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"><div=
>I don&#39;t think anyone here disagrees with this.=C2=A0 The question is w=
hat do<br></div><div>most authors prefer, correctness or performance?=C2=A0=
 I don&#39;t know anyone</div><div>who would say &quot;I&#39;ll take the wr=
ong answer, just give it to me fast.&quot;</div></div></blockquote><div><br=
></div><div>I want the right answer, as fast as possible, w/o me having to =
write convoluted / non-portable code because the compiler isn&#39;t allowed=
 to optimize my code.=C2=A0 I want unicorns, too. :-)</div></div></div></bl=
ockquote><div><br></div><div>The important part there being &quot;the right=
 answer&quot;. =C2=A0We&#39;re</div><div>currently writing non-portable cod=
e without even knowing it.</div></blockquote><div><br></div><div>Are we? Ho=
w often in practice does one (a) create an impure value-returning function =
and (b) use it in a non-sequenced expression?</div><div>=C2=A0</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></div><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 class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div>This sounds like the<br></div></div></blockquote><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"><div>strict aliasing options in gcc/clang.</d=
iv></div></blockquote><div><br></div><div>Which is beyond the purview of th=
e standard.</div></div></div></blockquote><div><br></div><div>I didn&#39;t =
say anything about the standard. =C2=A0I said the</div><div>optimizer write=
rs could give the users this option.</div></blockquote><div><br></div><div>=
Turning on strict aliasing still gives a conformant compiler. If you change=
 the standard to disallow evaluation reordering, then such an option would =
make the compiler nonconformant when it is turned on.</div><div><br></div><=
div>If there were demand from users to allow order-dependent code, gcc woul=
d have an option (as -fno-strict-aliasing) to=C2=A0disallow=C2=A0evaluation=
=C2=A0reordering.=C2=A0It doesn&#39;t, apart=C2=A0from -O0.</div><div><br><=
/div><div>Also, perhaps OT, but optimizations aren&#39;t the only program t=
ransformation that would be impeded by disallowing=C2=A0evaluation=C2=A0reo=
rdering. Changing the order of function parameters is a common occurrence d=
uring API evolution or substitution, certainly common enough that both Visu=
al Assist and ReSharper have it as a builtin task. Would you make that ille=
gal?</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">
</div>
</blockquote></blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_9178_64292949.1452021714243--
------=_Part_9177_343482577.1452021714242--

.

On 01/05/2016 08:02 PM, Hyman Rosen wrote:
> On Tue, Jan 5, 2016 at 1:03 PM, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp <mailto:k_satoda@f2.dion.ne.jp>> wrote:
>
>     Even if all "pure(non_local)" in the example are replaced to
>     "non_local", the unspecified OOE still in effect such that the load from
>     memory (non_local) can be collapsed into once instead of twice.
>
>
> Given the code
>     int x(int);
>     struct S { int m; S(); int f() { return x(m - m % 2) + (m - m % 2); } } s;
>     int main(int c, char **v) { return s.f(); }
> on x86 both gcc and clang recompute the m - m % 2 subexpression after x returns,even with -O6/-O3 specified.

Hm...  That sounds like a missed optimization opportunity.

Jens

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Tue, Jan 5, 2016 at 3:03 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> Hm...  That sounds like a missed optimization opportunity.


That's the point - it's evidence against the "but optimization!" people,
demonstrating a case where defining strict left-to-right order of
evaluation would prevent an optimization, but it's an optimization that
compilers aren't doing even though they're allowed to.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1143fae042458405289be313
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, Jan 5, 2016 at 3:03 PM, Jens Maurer <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.net</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">Hm...=C2=A0 That sounds like a=
 missed optimization opportunity.</blockquote><div><br>That&#39;s the point=
 - it&#39;s evidence against the &quot;but optimization!&quot; people, demo=
nstrating a case where defining strict left-to-right order of evaluation wo=
uld prevent an optimization, but it&#39;s an optimization that compilers ar=
en&#39;t doing even though they&#39;re allowed to.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1143fae042458405289be313--

.

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

On Tue, Jan 5, 2016 at 8:14 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Tue, Jan 5, 2016 at 3:03 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
>
>> Hm...  That sounds like a missed optimization opportunity.
>
>
> That's the point - it's evidence against the "but optimization!" people,
> demonstrating a case where defining strict left-to-right order of
> evaluation would prevent an optimization, but it's an optimization that
> compilers aren't doing even though they're allowed to.
>
> gcc will eliminate the redundant recomputation if the addition is replaced
by a function call (to e.g. int a(int i, int j) { return i + j; }).

icc will not perform this precise optimization, but will move a preceding
computation to after the call to x, so simplifying (m - m % 2) + x(m - m %
2) + (m - m % 2) to x(m - m % 2) + 2 * (m - m % 2).

So there's two compilers that do perform a closely related optimization.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1133bf6c0edd8005289c2c32
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, Jan 5, 2016 at 8:14 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@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);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><span class=3D"">On Tue, Jan 5, 2016 at 3:03=
 PM, Jens Maurer <span dir=3D"ltr">&lt;<a href=3D"mailto:Jens.Maurer@gmx.ne=
t" target=3D"_blank">Jens.Maurer@gmx.net</a>&gt;</span> wrote:<br><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">Hm...=C2=A0 That sounds like a missed optimization opportunity.</bl=
ockquote></span><div><br>That&#39;s the point - it&#39;s evidence against t=
he &quot;but optimization!&quot; people, demonstrating a case where definin=
g strict left-to-right order of evaluation would prevent an optimization, b=
ut it&#39;s an optimization that compilers aren&#39;t doing even though the=
y&#39;re allowed to.</div></div></div></div><div class=3D""><div class=3D"h=
5">

<p></p></div></div></blockquote></div></div><div class=3D"gmail_extra"><div=
>gcc will eliminate the redundant recomputation if the addition is replaced=
 by a function call (to e.g. int a(int i, int j) { return i + j; }).</div><=
div><br></div><div>icc will not perform this precise optimization, but will=
 move a preceding computation to after the call to x, so simplifying=C2=A0<=
span style=3D"color:rgb(80,0,80);font-size:12.8000001907349px"><font face=
=3D"monospace, monospace">(m - m % 2) +=C2=A0</font></span><span style=3D"f=
ont-size:12.8000001907349px"><font face=3D"monospace, monospace" style=3D"c=
olor:rgb(80,0,80)">x(m - m % 2) + (m - m % 2)</font><font color=3D"#000000"=
> to=C2=A0</font></span><span style=3D"color:rgb(80,0,80);font-size:12.8000=
001907349px"><font face=3D"monospace, monospace">x(m - m % 2) + 2 * (m - m =
% 2)</font></span>.</div><div><br></div><div>So there&#39;s two compilers t=
hat do perform a closely related optimization.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1133bf6c0edd8005289c2c32--

.

------=_Part_923_1303880593.1452028525645
Content-Type: multipart/alternative;
 boundary="----=_Part_924_2141077844.1452028525645"

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

On Tuesday, 29 December 2015 20:17:46 UTC, Arthur O'Dwyer wrote:
>
> I mean, there are only a finite number of Clang developers, right? Which=
=20
> feature would you rather they spend time on: optimizations in general, or=
=20
> an evaluation-order sanitizer in particular? Because under the *current*=
=20
> state of affairs, we're basically telling them they *have* to write an=20
> evaluation-order sanitizer, just in order to detect and diagnose all the=
=20
> buggy non-portable code that our fellow software engineers are writing=20
> every day. If we could just nail down the evaluation order in the standar=
d,=20
> so that it became defined and portable, then that problem would completel=
y=20
> go away =E2=80=94 no Clang developer would have to spend a minute longer =
on that=20
> particular sanitizer =E2=80=94 and they could turn their efforts away fro=
m=20
> "cleaning up after C++'s messes" and back toward "writing neat codegen=20
> optimizations." ;)
>

Developer time and effort is not fungible; the developers writing=20
sanitizers are not necessarily the same as those writing optimizations.=20
Even when one developer is capable and interested in writing both,=20
sponsorship may be available for one and not the other.

Also, we *already* have -Wsequence-point, which catches the most egregious=
=20
instances of the issue, and the majority of those resulting in UB. Those=20
which affect program output but not definedness are not necessarily bugs;=
=20
there's not much left for a putative sanitizer to cover.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

On Tuesday, 29 December 2015 20:17:46 UTC, Arthur O&#39;Dwyer  wrote:<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 class=3D"gmail=
_quote"><div>I mean, there are only a finite number of Clang developers, ri=
ght? Which feature would you rather they spend time on: optimizations in ge=
neral, or an evaluation-order sanitizer in particular? Because under the <i=
>current</i> state of affairs, we&#39;re basically telling them they <i>hav=
e</i> to write an evaluation-order sanitizer, just in order to detect and d=
iagnose all the buggy non-portable code that our fellow software engineers =
are writing every day. If we could just nail down the evaluation order in t=
he standard, so that it became defined and portable, then that problem woul=
d completely go away =E2=80=94 no Clang developer would have to spend a min=
ute longer on that particular sanitizer =E2=80=94 and they could turn their=
 efforts away from &quot;cleaning up after C++&#39;s messes&quot; and back =
toward &quot;writing neat codegen optimizations.&quot; ;)</div></div></div>=
</blockquote><div><br></div><div>Developer time and effort is not fungible;=
 the developers writing sanitizers are not necessarily the same as those wr=
iting optimizations. Even when one developer is capable and interested in w=
riting both, sponsorship may be available for one and not the other.</div><=
div><br></div><div>Also, we *already* have -Wsequence-point, which catches =
the most egregious instances of the issue, and the majority of those result=
ing in UB. Those which affect program output but not definedness are not ne=
cessarily bugs; there&#39;s not much left for a putative sanitizer to cover=
..</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_924_2141077844.1452028525645--
------=_Part_923_1303880593.1452028525645--

.

On 01/05/2016 09:14 PM, Hyman Rosen wrote:
> On Tue, Jan 5, 2016 at 3:03 PM, Jens Maurer <Jens.Maurer@gmx.net <mailto:Jens.Maurer@gmx.net>> wrote:
>
>     Hm...  That sounds like a missed optimization opportunity.
>
>
> That's the point - it's evidence against the "but optimization!"
> people, demonstrating a case where defining strict left-to-right
> order of evaluation would prevent an optimization, but it's an
> optimization that compilers aren't doing even though they're allowed
> to.

To the contrary, it's a case where I can easily see a future
optimizer benefiting from "no sequencing for +".
That (very reasonable) optimization would be precluded by
specifying left-to-right optimization for +.

(A sibling post shows the optimization is performed if +
is replaced by a function call.)

To be fair, imposing ordering for + is not on the table with
the current proposal.

Jens

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Tue, Jan 5, 2016 at 4:21 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> On 01/05/2016 09:14 PM, Hyman Rosen wrote:
> > On Tue, Jan 5, 2016 at 3:03 PM, Jens Maurer <Jens.Maurer@gmx.net
> <mailto:Jens.Maurer@gmx.net>> wrote:
> >
> >     Hm...  That sounds like a missed optimization opportunity.
> >
> >
> > That's the point - it's evidence against the "but optimization!"
> > people, demonstrating a case where defining strict left-to-right
> > order of evaluation would prevent an optimization, but it's an
> > optimization that compilers aren't doing even though they're allowed
> > to.
>
> To the contrary, it's a case where I can easily see a future
> optimizer benefiting from "no sequencing for +".
> That (very reasonable) optimization would be precluded by
> specifying left-to-right optimization for +.
>

Future optimizer. This freedom has been available to the optimizers for the
better part of the last 2 decades and you still think some day they will
wake up to it. I guess, in the immortal words of Nicol Bolas:

""In the future" is not "today". It's not "now". There is no way to
quantify what *could happen* in the future. Why should we prepare for some
future that may never happen, when we can instead deal with problems we
already have?"

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11411138fc070a0528a03725
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, Jan 5, 2016 at 4:21 PM, Jens Maurer <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.net</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-widt=
h:1px;border-left-style:solid">On 01/05/2016 09:14 PM, Hyman Rosen wrote:<b=
r>
<span>&gt; On Tue, Jan 5, 2016 at 3:03 PM, Jens Maurer &lt;<a href=3D"mailt=
o:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.net</a> &lt;mailto=
:<a href=3D"mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.n=
et</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0Hm...=C2=A0 That sounds like a missed optimization =
opportunity.<br>
&gt;<br>
&gt;<br>
&gt; That&#39;s the point - it&#39;s evidence against the &quot;but optimiz=
ation!&quot;<br>
&gt; people, demonstrating a case where defining strict left-to-right<br>
&gt; order of evaluation would prevent an optimization, but it&#39;s an<br>
&gt; optimization that compilers aren&#39;t doing even though they&#39;re a=
llowed<br>
&gt; to.<br>
<br>
</span>To the contrary, it&#39;s a case where I can easily see a future<br>
optimizer benefiting from &quot;no sequencing for +&quot;.<br>
That (very reasonable) optimization would be precluded by<br>
specifying left-to-right optimization for +.<br></blockquote><div><br></div=
><div>Future optimizer.=C2=A0This freedom has been available to the optimiz=
ers for the better part of=C2=A0the last 2 decades and you still think some=
 day they will wake up to it. I guess,=C2=A0in the immortal words of Nicol =
Bolas:</div><div><br></div><div>&quot;&quot;In the future&quot; is not &quo=
t;today&quot;. It&#39;s not &quot;now&quot;. There is no way to quantify wh=
at <i>could happen</i> in the future. Why should we prepare for some future=
 that may never happen, when we can instead deal with problems we already h=
ave?&quot;</div><div><br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a11411138fc070a0528a03725--

.

------=_Part_11780_380025784.1452045583642
Content-Type: multipart/alternative;
 boundary="----=_Part_11781_385008188.1452045583643"

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

On Tuesday, January 5, 2016 at 10:11:12 AM UTC-5, Matthew Woehlke wrote:
>
> On 2016-01-04 19:45, Greg Marr wrote:=20
> > On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote=
:=20
> >> What is the impact of doing so?  I've yet to see anyone quantify it,=
=20
> >> produce a reasonable benchmark, etc.=20
> >=20
> > The impact of not doing an optimization that no one currently does?=20
>
> Well... yes :-). That's one of the major problems; we *can't* (readily)=
=20
> quantify the cost, because it's a cost in potential, not a cost that=20
> directly affects actual current practice. (And, no, I don't agree with=20
> Nicol that potential costs / potential benefits are irrelevant.)=20
>

They're not necessarily irrelevant, but if they can't be measured, then it'=
s
very hard to weigh their potential benefit against the measurable benefit o=
f
eliminating surprising orders of operations.
=20

> This is true for both directions; part=C2=B9 of the purported benefit is =
in=20
> relieving programmers from having to think about (or, more importantly,=
=20
> be taught about=C2=B2) OOE issues.=20
>
> (=C2=B9 Please note that I said *"part"*. I'm well aware there is also=20
> currently measurable cost in bugs due to OOE issues.)=20
>
> (=C2=B2 I would say I am not *consciously* aware of OOE issues, but simpl=
y in=20
> the habit of avoiding them. Maybe even "on principle". This, as was=20
> mentioned elsewhere, is also an important point; if we continue to avoid=
=20
> OOE-dependent code for other reasons, the alleged benefit in not having=
=20
> to teach new programmers about it is significantly reduced.)=20
>

I would say that is a very small part, the first note being the much
more important part.  Are you sure that you always avoid OOE errors?
=20

> >> If we nail down the order, there is effectively no way to discourage=
=20
> >> writing order-dependent code.=20
> >=20
> > Sure there is, see above. We can discourage it the same way we=20
> > discourage naked new.=20
>
> ...in which case, as above, much of the benefit evaporates, thereby=20
> significantly weakening the argument in favor of defined OOE.


How so?  Discourage is not the same as eliminate.
=20

> > I think it is ridiculous to simply tell people not to rely on any order=
..=20
> >  We know that doesn't work.=20
>
> ...and yet, this contradicts your previous comment.=20
>

How so?  Tell people not to rely on a particular order, tell them when we=
=20
know
that they do rely on a particular order, but still give them a particular=
=20
order
as much as practical for when they don't use the checking tools or the=20
checking
tools can't know.

> if (i =3D 0)=20
> > {=20
> > }=20
>
> OT, but this exact example is *almost* certainly an error, especially in=
=20
> production code, because the conditional is non-trivial but still is=20
> always false. It *is* technically conforming, but I would hope that all=
=20
> compilers warn about it by default. ('if (x =3D y)' would be a better=20
> example; I can readily imagine this code being correct, while it's much=
=20
> harder to imagine the above ever being correct.)=20
>

Fine, replace my example with if (x =3D y) if it makes it easier to=20
understand.
The value on the right side of the assignment wasn't the important part.
=20

> On 2016-01-04 22:28, Greg Marr wrote:=20
> > Have you not seen the posts in this thread about the code which=20
> > existed in print for many years, read by many language experts,=20
> > before the order of evaluation errors were found?=20
>
> I actually can't say that I have. I *think* I've read the entire thread,=
=20
> but considering the length, you might want to point them out again.=20
>

I'll pull out the one from the proposal itself.  This may or may not be the
one referenced in this thread.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf

Consider the following program fragment:

void f()
{
    std::string s =3D =E2=80=9Cbut I have heard it works even if you don=E2=
=80=99t believe in=20
it=E2=80=9D;
    s.replace(0, 4, =E2=80=9C=E2=80=9D).replace(s.find(=E2=80=9Ceven=E2=80=
=9D), 4, =E2=80=9Conly=E2=80=9D).replace(s.find(=E2=80=9C=20
don=E2=80=99t=E2=80=9D), 6, =E2=80=9C=E2=80=9D);
    assert(s =3D=3D =E2=80=9CI have heard it works only if you believe in i=
t=E2=80=9D);
}

The assertion is supposed to validate the programmer=E2=80=99s intended res=
ult. It=20
uses =E2=80=9Cchaining=E2=80=9D of member function calls, a common standard=
 practice. This=20
code has been reviewed by C++ experts world-wide, and published (The C++=20
Programming Language, 4th edition.) Yet, its vulnerability to unspecified=
=20
order of evaluation has been discovered only recently by a tool.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">On Tuesday, January 5, 2016 at 10:11:12 AM UTC-5, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-01-04 19=
:45, Greg Marr wrote:
<br>&gt; On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin &quot;:-)&qu=
ot; Liber wrote:
<br>&gt;&gt; What is the impact of doing so? =C2=A0I&#39;ve yet to see anyo=
ne quantify it,=20
<br>&gt;&gt; produce a reasonable benchmark, etc.
<br>&gt;=20
<br>&gt; The impact of not doing an optimization that no one currently does=
?
<br>
<br>Well... yes :-). That&#39;s one of the major problems; we *can&#39;t* (=
readily)
<br>quantify the cost, because it&#39;s a cost in potential, not a cost tha=
t
<br>directly affects actual current practice. (And, no, I don&#39;t agree w=
ith
<br>Nicol that potential costs / potential benefits are irrelevant.)
<br></blockquote><div><br></div><div>They&#39;re not necessarily irrelevant=
, but if they can&#39;t be measured, then it&#39;s</div><div>very hard to w=
eigh their potential benefit against the measurable benefit of</div><div>el=
iminating surprising orders of operations.</div><div>=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;">This is true for both directions; pa=
rt=C2=B9 of the purported benefit is in
<br>relieving programmers from having to think about (or, more importantly,
<br>be taught about=C2=B2) OOE issues.
<br>
<br>(=C2=B9 Please note that I said *&quot;part&quot;*. I&#39;m well aware =
there is also
<br>currently measurable cost in bugs due to OOE issues.)
<br>
<br>(=C2=B2 I would say I am not *consciously* aware of OOE issues, but sim=
ply in
<br>the habit of avoiding them. Maybe even &quot;on principle&quot;. This, =
as was
<br>mentioned elsewhere, is also an important point; if we continue to avoi=
d
<br>OOE-dependent code for other reasons, the alleged benefit in not having
<br>to teach new programmers about it is significantly reduced.)
<br></blockquote><div><br></div><div>I would say that is a very small part,=
 the first note being the much</div><div>more important part. =C2=A0Are you=
 sure that you always avoid OOE errors?</div><div>=C2=A0<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">&gt;&gt; If we nail down the order, the=
re is effectively no way to discourage=20
<br>&gt;&gt; writing order-dependent code.
<br>&gt;=20
<br>&gt; Sure there is, see above. We can discourage it the same way we
<br>&gt; discourage naked new.
<br>
<br>...in which case, as above, much of the benefit evaporates, thereby
<br>significantly weakening the argument in favor of defined OOE.</blockquo=
te><div><br></div><div>How so? =C2=A0Discourage is not the same as eliminat=
e.</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;">&gt; =
I think it is ridiculous to simply tell people not to rely on any order.=20
<br>&gt; =C2=A0We know that doesn&#39;t work.
<br>
<br>...and yet, this contradicts your previous comment.
<br></blockquote><div><br></div><div>How so? =C2=A0Tell people not to rely =
on a particular order, tell them when we know</div><div>that they do rely o=
n a particular order, but still give them a particular order</div><div>as m=
uch as practical for when they don&#39;t use the checking tools or the chec=
king</div><div>tools can&#39;t know.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">&gt; if (i =3D 0)
<br>&gt; {
<br>&gt; }
<br>
<br>OT, but this exact example is *almost* certainly an error, especially i=
n
<br>production code, because the conditional is non-trivial but still is
<br>always false. It *is* technically conforming, but I would hope that all
<br>compilers warn about it by default. (&#39;if (x =3D y)&#39; would be a =
better
<br>example; I can readily imagine this code being correct, while it&#39;s =
much
<br>harder to imagine the above ever being correct.)
<br></blockquote><div><br></div><div>Fine, replace my example with if (x =
=3D y) if it makes it easier to understand.</div><div>The value on the righ=
t side of the assignment wasn&#39;t the important part.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-01-04 22:28, Greg M=
arr wrote:
<br>&gt; Have you not seen the posts in this thread about the code which
<br>&gt; existed in print for many years, read by many language experts,
<br>&gt; before the order of evaluation errors were found?
<br>
<br>I actually can&#39;t say that I have. I *think* I&#39;ve read the entir=
e thread,
<br>but considering the length, you might want to point them out again.
<br></blockquote><div><br></div><div>I&#39;ll pull out the one from the pro=
posal itself. =C2=A0This may or may not be the</div><div>one referenced in =
this thread.</div><div><br></div><div>http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2015/p0145r0.pdf<br></div><div><br></div><div>Consider the fo=
llowing program fragment:</div><div><br></div><div>void f()</div><div>{</di=
v><div>=C2=A0 =C2=A0 std::string s =3D =E2=80=9Cbut I have heard it works e=
ven if you don=E2=80=99t believe in it=E2=80=9D;</div><div>=C2=A0 =C2=A0 s.=
replace(0, 4, =E2=80=9C=E2=80=9D).replace(s.find(=E2=80=9Ceven=E2=80=9D), 4=
, =E2=80=9Conly=E2=80=9D).replace(s.find(=E2=80=9C don=E2=80=99t=E2=80=9D),=
 6, =E2=80=9C=E2=80=9D);</div><div>=C2=A0 =C2=A0 assert(s =3D=3D =E2=80=9CI=
 have heard it works only if you believe in it=E2=80=9D);</div><div>}</div>=
<div><br></div><div>The assertion is supposed to validate the programmer=E2=
=80=99s intended result. It uses =E2=80=9Cchaining=E2=80=9D of member
function calls, a common standard practice. This code has been reviewed by =
C++ experts world-wide, and
published (The C++ Programming Language, 4th edition.) Yet, its vulnerabili=
ty to unspecified order of
evaluation has been discovered only recently by a tool.</div><div><br></div=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_11781_385008188.1452045583643--
------=_Part_11780_380025784.1452045583642--

.

------=_Part_8587_38442946.1452047470744
Content-Type: multipart/alternative;
 boundary="----=_Part_8588_2122352807.1452047470745"

------=_Part_8588_2122352807.1452047470745
Content-Type: text/plain; charset=UTF-8

On Tuesday, January 5, 2016 at 9:29:19 AM UTC-5, Matthew Woehlke wrote:
>
> On 2016-01-04 17:31, Greg Marr wrote:
> > On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wrote:
> >> There's "correctness" and there's "correctness". Right now, there is
> >> widespread discouragement against writing order-sensitive code in the
> >> first place (in the sense of 'OOE will affect the result'). Thus, the
> >> starting assumption is that the code "works", regardless of OOE.
> >
> > I want to be sure I understand what you mean.  I see two possible
> > interpretations here:
> >
> > 1. Because of all the discouragement against writing order-sensitive
> > code, we should assume that all code that has ever been written
> > works regardless of OOE because everyone knows not to rely on it,
> > and can recognize and avoid all OOE errors.
>
> That's... stronger than I would put it. There is still room here for
> e.g. sanitizers. The point is more that a) there is debate over just how
> badly broken things really are in this area, and b) there exists much
> code that is correct *even though OOE is unspecified*.
>
> > 2. The particular bit of code that is discussed next works regardless
> > of OOE because the author knows not to rely on it and has done
> > the necessary research to determine that the code is okay,
>
> Again, that's a little strong. I would say it works regardless of OOE
> because the API is well designed and free of surprising side effects.
> That is, I believe that *MUCH* more code is written that "just happens
> to work" regardless of OOE than runs afoul of OOE.


I agree, there is much more code that is OOE safe than has OOE problems.
In fact, that's part of the problem.  Most of your code can be fine, but
then
you hit that one place that has it, and it just happens to work with your
current compilation environment, and then boom, something changes, and
it doesn't work any more, and you can't find it.

That's the danger in "the starting assumption" being "that the code "works",
regardless of OOE".  It works only until it doesn't.

>> Or, to put it more succinctly, defined ordering severely restricts CSE
> >> compared to the current situation.
> >
> > I don't think anyone here disagrees with this.  The question is what do
> > most authors prefer, correctness or performance?
>
> Again, I think this overstates the case. You're presenting the question
> as black and white, when reality is somewhere in between. There is a
> cost to errors due to unspecified OOE. There is also a cost to lost
> optimization due to forcing a particular OOE unnecessarily. A fair
> assessment cannot be given without considering the *values* of those
> costs (even if one is weighted more heavily).


That's true.  It's so very difficult to compare them, however, because one
cost is very real, and one cost is for a potential future benefit.

I really do understand the desire for more optimization opportunities.
How many other optimizations would we be able to make if we relaxed OOE
requirements in other parts of the standard, and just told people what they
needed to do or avoid to write proper code?  Would anyone even consider
proposing them?  I think there is a temptation to keep this optimization
potential available at all costs simply because the potential is currently
there,
even though it's not realized.  I think that if the order had been set from
the
beginning, no one would now be clamoring for it to be relaxed in order to
enable these particular optimization potentials.  It's seeing the potential
slipping through our fingers, and trying very hard to hold on to it.

I think the route to this particular optimization just needs to be through
"as-if", with more whole-program knowledge being made available to the
optimizers.  There are advances in optimization technology fairly regularly
now, whole program optimization, auto vectorization, auto parallelization.

For instance, I don't think we would be having this discussion if the
> performance cost made 80% of all code take twice as long to execute
> while there exists a single, contrived example of where someone *might*
> be bitten by unspecified OOE. Obviously, I am exaggerating for effect,
> but the point is that a) it isn't just black-and-white, and b) my own
> perception of the relative costs does not match what I perceive as
> others implying those costs to be.


I'd agree with that, (having myself exaggerated for effect a bit in a
previous post quoted above).

And, as I've stated previously, part of why I'm arguing is as much
> because I feel like there needs to be *someone* arguing against, just
> for the sake of having a complete understanding of the potential
> drawbacks, because there is an impression that this hasn't been taking
> place.


Understood, though it does seem pretty evident that it has been taking
place:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf

We propose to revise C++ evaluation rules to support decades-old idiomatic
constructs and programming practices. A simple solution would be to require
that every expression has a well-defined evaluation order. That suggestion
has traditionally met resistance for various reasons. Rather, this proposal
suggests a more targeted fix:


> > If optimizer writers want to make an option that says "assume that all
> > code has no OOE dependencies in it, and act as if the C++14 rules were
> > still in place" for those authors that write performance critical code
> where
> > they've already evaluated all of the OOE dependencies, I'd be fine with
> > that,
>
> Yes, at the least I rather expect compilers to develop a
> -funspecified-order (or similar) option if C++17 has defined OOE.
>
> What makes such flags difficult, of course, is that it's hard to employ
> them on a fine-grained basis.
>

That brings up an interesting point, that someone employing this would
want, or perhaps need, to employ them on a fine-grained basis, rather
than using it globally, because they're not sure of all the areas that
might have OOE issues.


> FWIW, the potential performance impact would be substantially mitigated
> if we had standard ways to annotate what side effects are permitted. One
> problem is that right now we lack standard tools to assist the compiler
> with as-if evaluation. If we had those (even better, if we'd had them
> for some years and they were as widely employed as 'const'),


That would be great.


> we probably
> wouldn't be having this conversation.


That would be great too.  As much as I enjoy a lively technical debate,
they all too often end up being, or being interpreted as, personal rather
than technical.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Tuesday, January 5, 2016 at 9:29:19 AM UTC-5, Matthew Woehlke wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On 2016-01-04 17:31, Greg Marr wro=
te:
<br>&gt; On Monday, January 4, 2016 at 4:45:52 PM UTC-5, Matthew Woehlke wr=
ote:
<br>&gt;&gt; There&#39;s &quot;correctness&quot; and there&#39;s &quot;corr=
ectness&quot;. Right now, there is=20
<br>&gt;&gt; widespread discouragement against writing order-sensitive code=
 in the=20
<br>&gt;&gt; first place (in the sense of &#39;OOE will affect the result&#=
39;). Thus, the=20
<br>&gt;&gt; starting assumption is that the code &quot;works&quot;, regard=
less of OOE.=20
<br>&gt;=20
<br>&gt; I want to be sure I understand what you mean. =C2=A0I see two poss=
ible
<br>&gt; interpretations here:
<br>&gt;=20
<br>&gt; 1. Because of all the discouragement against writing order-sensiti=
ve
<br>&gt; code, we should assume that all code that has ever been written=20
<br>&gt; works regardless of OOE because everyone knows not to rely on it,
<br>&gt; and can recognize and avoid all OOE errors.
<br>
<br>That&#39;s... stronger than I would put it. There is still room here fo=
r
<br>e.g. sanitizers. The point is more that a) there is debate over just ho=
w
<br>badly broken things really are in this area, and b) there exists much
<br>code that is correct *even though OOE is unspecified*.
<br>
<br>&gt; 2. The particular bit of code that is discussed next works regardl=
ess
<br>&gt; of OOE because the author knows not to rely on it and has done
<br>&gt; the necessary research to determine that the code is okay,
<br>
<br>Again, that&#39;s a little strong. I would say it works regardless of O=
OE
<br>because the API is well designed and free of surprising side effects.
<br>That is, I believe that *MUCH* more code is written that &quot;just hap=
pens
<br>to work&quot; regardless of OOE than runs afoul of OOE.</blockquote><di=
v><br></div><div>I agree, there is much more code that is OOE safe than has=
 OOE problems.</div><div>In fact, that&#39;s part of the problem. =C2=A0Mos=
t of your code can be fine, but then</div><div>you hit that one place that =
has it, and it just happens to work with your</div><div>current compilation=
 environment, and then boom, something changes, and</div><div>it doesn&#39;=
t work any more, and you can&#39;t find it.</div><div><br></div><div>That&#=
39;s the danger in &quot;the starting assumption&quot; being &quot;that the=
 code &quot;works&quot;,</div><div>regardless of OOE&quot;. =C2=A0It works =
only until it doesn&#39;t.</div><div><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;">&gt;&gt; Or, to put it more succinctly, defined ordering s=
everely restricts CSE=20
<br>&gt;&gt; compared to the current situation.=20
<br>&gt;=20
<br>&gt; I don&#39;t think anyone here disagrees with this. =C2=A0The quest=
ion is what do
<br>&gt; most authors prefer, correctness or performance?
<br>
<br>Again, I think this overstates the case. You&#39;re presenting the ques=
tion
<br>as black and white, when reality is somewhere in between. There is a
<br>cost to errors due to unspecified OOE. There is also a cost to lost
<br>optimization due to forcing a particular OOE unnecessarily. A fair
<br>assessment cannot be given without considering the *values* of those
<br>costs (even if one is weighted more heavily).</blockquote><div><br></di=
v><div>That&#39;s true. =C2=A0It&#39;s so very difficult to compare them, h=
owever, because one</div><div>cost is very real, and one cost is for a pote=
ntial future benefit.</div><div><br></div><div>I really do understand the d=
esire for more optimization opportunities. =C2=A0</div><div>How many other =
optimizations would we be able to make if we relaxed OOE</div><div>requirem=
ents in other parts of the standard, and just told people what they</div><d=
iv>needed to do or avoid to write proper code? =C2=A0Would anyone even cons=
ider</div><div>proposing them? =C2=A0I think there is a temptation to keep =
this optimization</div><div>potential available at all costs simply because=
 the potential is currently there,</div><div>even though it&#39;s not reali=
zed. =C2=A0I think that if the order had been set from the</div><div>beginn=
ing, no one would now be clamoring for it to be relaxed in order to</div><d=
iv>enable these particular optimization potentials. =C2=A0It&#39;s seeing t=
he potential</div><div>slipping through our fingers, and trying very hard t=
o hold on to it.</div><div><br></div><div>I think the route to this particu=
lar optimization just needs to be through</div><div>&quot;as-if&quot;, with=
 more whole-program knowledge being made available to the</div><div>optimiz=
ers. =C2=A0There are advances in optimization technology fairly regularly</=
div><div>now, whole program optimization, auto vectorization, auto parallel=
ization.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">F=
or instance, I don&#39;t think we would be having this discussion if the
<br>performance cost made 80% of all code take twice as long to execute
<br>while there exists a single, contrived example of where someone *might*
<br>be bitten by unspecified OOE. Obviously, I am exaggerating for effect,
<br>but the point is that a) it isn&#39;t just black-and-white, and b) my o=
wn
<br>perception of the relative costs does not match what I perceive as
<br>others implying those costs to be.</blockquote><div><br></div><div>I&#3=
9;d agree with that, (having myself exaggerated for effect a bit in a</div>=
<div>previous post quoted above).</div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">And, as I&#39;ve stated previously, part of why I&#=
39;m arguing is as much
<br>because I feel like there needs to be *someone* arguing against, just
<br>for the sake of having a complete understanding of the potential
<br>drawbacks, because there is an impression that this hasn&#39;t been tak=
ing
<br>place.</blockquote><div><br></div><div>Understood, though it does seem =
pretty evident that it has been taking place:</div><div><br></div><div>http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf<br></div><d=
iv><br></div><div>We propose to revise C++ evaluation rules to support deca=
des-old idiomatic</div><div>constructs and programming
practices. A simple solution would be to require</div><div>that every expre=
ssion has a well-defined evaluation
order. That suggestion</div><div>has traditionally met resistance for vario=
us reasons. Rather, this proposal</div><div>suggests
a more targeted fix:=C2=A0<br></div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">&gt; If optimizer writers want to make an option tha=
t says &quot;assume that all
<br>&gt; code has no OOE dependencies in it, and act as if the C++14 rules =
were
<br>&gt; still in place&quot; for those authors that write performance crit=
ical code where
<br>&gt; they&#39;ve already evaluated all of the OOE dependencies, I&#39;d=
 be fine with=20
<br>&gt; that,
<br>
<br>Yes, at the least I rather expect compilers to develop a
<br>-funspecified-order (or similar) option if C++17 has defined OOE.
<br>
<br>What makes such flags difficult, of course, is that it&#39;s hard to em=
ploy
<br>them on a fine-grained basis.
<br></blockquote><div><br></div><div>That brings up an interesting point, t=
hat someone employing this would</div><div>want, or perhaps need, to employ=
 them on a fine-grained basis, rather</div><div>than using it globally, bec=
ause they&#39;re not sure of all the areas that</div><div>might have OOE is=
sues.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">FW=
IW, the potential performance impact would be substantially mitigated
<br>if we had standard ways to annotate what side effects are permitted. On=
e
<br>problem is that right now we lack standard tools to assist the compiler
<br>with as-if evaluation. If we had those (even better, if we&#39;d had th=
em
<br>for some years and they were as widely employed as &#39;const&#39;),</b=
lockquote><div>=C2=A0</div><div>That would be great.</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"> we probably
<br>wouldn&#39;t be having this conversation.=C2=A0</blockquote><div><br></=
div><div>That would be great too. =C2=A0As much as I enjoy a lively technic=
al debate,</div><div>they all too often end up being, or being interpreted =
as, personal rather</div><div>than technical.</div><div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_8588_2122352807.1452047470745--
------=_Part_8587_38442946.1452047470744--

.

--047d7ba97e64be278c0528a17916
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 5, 2016 at 6:31 PM, Greg Marr <gregmmarr@gmail.com> wrote:


> I think the route to this particular optimization just needs to be throug=
h
>
the optimizers.  There are advances in optimization technology fairly
> regularly
> now, whole program optimization, auto vectorization, auto parallelization=
..
>

FWIW, agreed. I'm a big believer in the power of the as-if rule.


> On Tuesday, January 5, 2016 at 9:29:19 AM UTC-5, Matthew Woehlke wrote:
>>
>> > If optimizer writers want to make an option that says "assume that all
>>
> > code has no OOE dependencies in it, and act as if the C++14 rules were
>> > still in place" for those authors that write performance critical code
>> where
>> > they've already evaluated all of the OOE dependencies, I'd be fine wit=
h
>> > that,
>>
>> Yes, at the least I rather expect compilers to develop a
>> -funspecified-order (or similar) option if C++17 has defined OOE.
>>
>> What makes such flags difficult, of course, is that it's hard to employ
>> them on a fine-grained basis.
>>
>
> That brings up an interesting point, that someone employing this would
> want, or perhaps need, to employ them on a fine-grained basis, rather
> than using it globally, because they're not sure of all the areas that
> might have OOE issues.
>

The flip side of that coin is: Someone employing the -funspecified-order
flag might *need* to employ it on a fine-grained basis, rather than
globally,
because now that the OOE is well-defined, his coworkers are going to be
writing code that exploits the well-defined OOE, and turning on
-funspecified-order
for their code would break things just as surely as turning on -ffast-math
would break certain kinds of numeric code.

So, in C++14 terms, we could say that his coworkers are writing code that
"has OOE issues", but in this hypothetical future where OOE is well-defined=
,
we would just say that their code "depends on the standard OOE".

Such code wouldn't necessarily have to be ugly or unreadable, either.
It might be simple stuff like "x + next(x)", or it might be some very deepl=
y
hidden assumption inside a template parameter-pack expansion, maybe
even being used with synchronization primitives where it *matters* what
order the side effects happen in. People do that kind of thing today, in
places where the OOE is guaranteed. How many times have you seen
"You need to declare mMutex first and then mLock second, otherwise
they'll be initialized in the wrong order and you'll get undefined
behavior."
? Imagine if there were a compiler flag
"-funspecified-member-initialization-order"
=E2=80=94 wouldn't you demand that it could be applied selectively?

Maybe the feature would be provided as a #pragma begin(...)/end(...)
type of thing, I don't know. I agree that it would need some thinking-out.

=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">On Tue, Jan 5, 2016 at 6:31 PM, Greg Marr <span dir=3D"ltr=
">&lt;<a href=3D"mailto:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@gm=
ail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><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-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div>I think the route to thi=
s particular optimization just needs to be through=C2=A0</div></blockquote>=
<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;p=
adding-left:1ex"><div>the optimizers.=C2=A0 There are advances in optimizat=
ion technology fairly regularly</div><div>now, whole program optimization, =
auto vectorization, auto parallelization.</div></blockquote><div><br></div>=
<div>FWIW, agreed. I&#39;m a big believer in the power of the as-if rule.</=
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);bord=
er-left-style:solid;padding-left:1ex"><span class=3D""><div></div><span cla=
ss=3D"">On Tuesday, January 5, 2016 at 9:29:19 AM UTC-5, Matthew Woehlke wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">&gt; If optimizer writers want to make an option that =
says &quot;assume that all=C2=A0<br></blockquote></span></span><span class=
=3D""><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">&gt; code has no OOE dependencies in it, and act as =
if the C++14 rules were
<br>&gt; still in place&quot; for those authors that write performance crit=
ical code where
<br>&gt; they&#39;ve already evaluated all of the OOE dependencies, I&#39;d=
 be fine with=20
<br>&gt; that,
<br>
<br>Yes, at the least I rather expect compilers to develop a
<br>-funspecified-order (or similar) option if C++17 has defined OOE.
<br>
<br>What makes such flags difficult, of course, is that it&#39;s hard to em=
ploy
<br>them on a fine-grained basis.
<br></blockquote><div><br></div></span><div>That brings up an interesting p=
oint, that someone employing this would</div><div>want, or perhaps need, to=
 employ them on a fine-grained basis, rather</div><div>than using it global=
ly, because they&#39;re not sure of all the areas that</div><div>might have=
 OOE issues.</div></blockquote><div><br></div><div>The flip side of that co=
in is: Someone employing the -funspecified-order</div><div>flag might <i>ne=
ed</i> to employ it on a fine-grained basis, rather than globally,</div><di=
v>because now that the OOE is well-defined, his coworkers are going to be</=
div><div>writing code that exploits the well-defined OOE, and turning on -f=
unspecified-order</div><div>for their code would break things just as surel=
y as turning on -ffast-math</div><div>would break certain kinds of numeric =
code.=C2=A0</div></div><br></div><div class=3D"gmail_extra">So, in C++14 te=
rms, we could say that his coworkers are writing code that</div><div class=
=3D"gmail_extra">&quot;has OOE issues&quot;, but in this hypothetical futur=
e where OOE is well-defined,</div><div class=3D"gmail_extra">we would just =
say that their code &quot;depends on the standard OOE&quot;.</div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Such code wouldn&#39=
;t necessarily have to be ugly or unreadable, either.</div><div class=3D"gm=
ail_extra">It might be simple stuff like &quot;x + next(x)&quot;, or it mig=
ht be some very deeply</div><div class=3D"gmail_extra">hidden assumption in=
side a template parameter-pack expansion, maybe</div><div class=3D"gmail_ex=
tra">even being used with synchronization primitives where it <i>matters</i=
> what</div><div class=3D"gmail_extra">order the side effects happen in. Pe=
ople do that kind of thing today, in</div><div class=3D"gmail_extra">places=
 where the OOE is guaranteed. How many times have you seen</div><div class=
=3D"gmail_extra">&quot;You need to declare mMutex first and then mLock seco=
nd, otherwise<br></div><div class=3D"gmail_extra">they&#39;ll be initialize=
d in the wrong order and you&#39;ll get undefined behavior.&quot;</div><div=
 class=3D"gmail_extra">? Imagine if there were a compiler flag &quot;-funsp=
ecified-member-initialization-order&quot;</div><div class=3D"gmail_extra">=
=E2=80=94 wouldn&#39;t you demand that it could be applied selectively?</di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Maybe the=
 feature would be provided as a #pragma begin(...)/end(...)</div><div class=
=3D"gmail_extra">type of thing, I don&#39;t know. I agree that it would nee=
d some thinking-out.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">=E2=80=93Arthur</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7ba97e64be278c0528a17916--

.

------=_Part_15447_826899811.1452059578792
Content-Type: multipart/alternative;
 boundary="----=_Part_15448_1713361861.1452059578793"

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



=E5=9C=A8 2016=E5=B9=B41=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8A=E5=8D=889:59:44=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A

>
> Consider the following program fragment:
>
> void f()
> {
>     std::string s =3D =E2=80=9Cbut I have heard it works even if you don=
=E2=80=99t believe=20
> in it=E2=80=9D;
>     s.replace(0, 4, =E2=80=9C=E2=80=9D).replace(s.find(=E2=80=9Ceven=E2=
=80=9D), 4,=20
> =E2=80=9Conly=E2=80=9D).replace(s.find(=E2=80=9C don=E2=80=99t=E2=80=9D),=
 6, =E2=80=9C=E2=80=9D);
>     assert(s =3D=3D =E2=80=9CI have heard it works only if you believe in=
 it=E2=80=9D);
> }
>
> The assertion is supposed to validate the programmer=E2=80=99s intended r=
esult. It=20
> uses =E2=80=9Cchaining=E2=80=9D of member function calls, a common standa=
rd practice. This=20
> code has been reviewed by C++ experts world-wide, and published (The C++=
=20
> Programming Language, 4th edition.) Yet, its vulnerability to unspecified=
=20
> order of evaluation has been discovered only recently by a tool.
>
> How common? I rarely see this style in real code and in the text of the=
=20
standard besides Clause 27. I have seen some people strongly dislike fluent=
=20
interface, perhaps because of difficulties on debugging and logging.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B41=E6=9C=886=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=889:59:44=EF=BC=8CGreg Marr=E5=
=86=99=E9=81=93=EF=BC=9A<br><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><br></div><div>Consider the following program fragment:=
</div><div><br></div><div>void f()</div><div>{</div><div>=C2=A0 =C2=A0 std:=
:string s =3D =E2=80=9Cbut I have heard it works even if you don=E2=80=99t =
believe in it=E2=80=9D;</div><div>=C2=A0 =C2=A0 s.replace(0, 4, =E2=80=9C=
=E2=80=9D).replace(s.find(=E2=80=9Ceven=E2=80=9D), 4, =E2=80=9Conly=E2=80=
=9D).replace(s.find(=E2=80=9C don=E2=80=99t=E2=80=9D), 6, =E2=80=9C=E2=80=
=9D);</div><div>=C2=A0 =C2=A0 assert(s =3D=3D =E2=80=9CI have heard it work=
s only if you believe in it=E2=80=9D);</div><div>}</div><div><br></div><div=
>The assertion is supposed to validate the programmer=E2=80=99s intended re=
sult. It uses =E2=80=9Cchaining=E2=80=9D of member
function calls, a common standard practice. This code has been reviewed by =
C++ experts world-wide, and
published (The C++ Programming Language, 4th edition.) Yet, its vulnerabili=
ty to unspecified order of
evaluation has been discovered only recently by a tool.</div><div><br></div=
></div></blockquote><div>How common? I rarely see this style in real code a=
nd in the text of the standard besides Clause 27. I have seen some people s=
trongly dislike fluent interface, perhaps because of difficulties on debugg=
ing and logging.<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_15448_1713361861.1452059578793--
------=_Part_15447_826899811.1452059578792--

.

On 2016-01-06 04:24, Dilip Ranganathan wrote:
> On Tue, Jan 5, 2016 at 4:21 PM, Jens Maurer <Jens.Maurer@gmx.net
> <mailto:Jens.Maurer@gmx.net>> wrote:
>
>     On 01/05/2016 09:14 PM, Hyman Rosen wrote:
>     > On Tue, Jan 5, 2016 at 3:03 PM, Jens Maurer <Jens.Maurer@gmx.net <mailto:Jens.Maurer@gmx.net>
>     <mailto:Jens.Maurer@gmx.net <mailto:Jens.Maurer@gmx.net>>> wrote:
>     >
>     >     Hm...  That sounds like a missed optimization opportunity.
>     >
>     >
>     > That's the point - it's evidence against the "but optimization!"
>     > people, demonstrating a case where defining strict left-to-right
>     > order of evaluation would prevent an optimization, but it's an
>     > optimization that compilers aren't doing even though they're allowed
>     > to.
>
>     To the contrary, it's a case where I can easily see a future
>     optimizer benefiting from "no sequencing for +".
>     That (very reasonable) optimization would be precluded by
>     specifying left-to-right optimization for +.
>
>
> Future optimizer. This freedom has been available to the optimizers for
> the better part of the last 2 decades and you still think some day they
> will wake up to it. I guess, in the immortal words of Nicol Bolas:
>
> ""In the future" is not "today". It's not "now". There is no way to
> quantify what /could happen/ in the future. Why should we prepare for
> some future that may never happen, when we can instead deal with
> problems we already have?"

To answer the quote, because you're not solving any problems. The code
that relies on OOE is broken now. Even if it magically works. If you
standardize the order of evaluation, it will be either just as broken or
smelly and you have to fix it anyway. You're limiting compilers for no
good reason.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-01-05 20:59, Greg Marr wrote:
> On Tuesday, January 5, 2016 at 10:11:12 AM UTC-5, Matthew Woehlke wrote:
>> On 2016-01-04 19:45, Greg Marr wrote:=20
>>> On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber wrote=
:=20
>>>> What is the impact of doing so?  I've yet to see anyone quantify it,=
=20
>>>> produce a reasonable benchmark, etc.=20
>>>
>>> The impact of not doing an optimization that no one currently does?=20
>>
>> Well... yes :-). That's one of the major problems; we *can't* (readily)=
=20
>> quantify the cost, because it's a cost in potential, not a cost that=20
>> directly affects actual current practice. (And, no, I don't agree with=
=20
>> Nicol that potential costs / potential benefits are irrelevant.)=20
>=20
> They're not necessarily irrelevant, but if they can't be measured, then i=
t's
> very hard to weigh their potential benefit against the measurable benefit=
 of
> eliminating surprising orders of operations.

No argument here :-). The question is thus, in light of that, how do we
weigh that unknown cost? My inclination, as I'm sure I've made known, is
"carefully". Others prefer to dismiss them entirely because they are not
readily quantified.

> Are you sure that you always avoid OOE errors?

Well, no, of course I can't be "sure". That would require some sort of
formal proof, or at least a reliable sanitizer. OTOH, I can't offhand
think of a *single* time that I've been bit by such an error.

>>>> If we nail down the order, there is effectively no way to discourage=
=20
>>>> writing order-dependent code.=20
>>>
>>> Sure there is, see above. We can discourage it the same way we=20
>>> discourage naked new.=20
>>
>> ...in which case, as above, much of the benefit evaporates, thereby=20
>> significantly weakening the argument in favor of defined OOE.
>=20
> How so?  Discourage is not the same as eliminate.

If we're discouraging it, we're still spending the effort to teach
people to avoid it, and people are still tending to avoid it. Therefore,
we won't see the tremendous gains claimed because people don't have to
worry about it any more; they still *will* be worrying about it.

>>> I think it is ridiculous to simply tell people not to rely on any order=
..=20
>>>  We know that doesn't work.=20
>>
>> ...and yet, this contradicts your previous comment.=20
>=20
> How so?

To quote:

>>> We can discourage [relying on a particular OOE] the same way we=20
>>> discourage naked new.

So you say it doesn't work, but also say we should continue to do it anyway=
..

>> On 2016-01-04 22:28, Greg Marr wrote:=20
>>> Have you not seen the posts in this thread about the code which=20
>>> existed in print for many years, read by many language experts,=20
>>> before the order of evaluation errors were found?=20
>>
>> I actually can't say that I have. I *think* I've read the entire thread,=
=20
>> but considering the length, you might want to point them out again.=20
>=20
> I'll pull out the one from the proposal itself.  This may or may not be t=
he
> one referenced in this thread.
>=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf
>=20
> Consider the following program fragment:
>=20
> void f()
> {
>     std::string s =3D =E2=80=9Cbut I have heard it works even if you don=
=E2=80=99t believe in=20
> it=E2=80=9D;
>     s.replace(0, 4, =E2=80=9C=E2=80=9D).replace(s.find(=E2=80=9Ceven=E2=
=80=9D), 4, =E2=80=9Conly=E2=80=9D).replace(s.find(=E2=80=9C=20
> don=E2=80=99t=E2=80=9D), 6, =E2=80=9C=E2=80=9D);
>     assert(s =3D=3D =E2=80=9CI have heard it works only if you believe in=
 it=E2=80=9D);
> }

Oh. Yes, I remember that now. Personally, I... think that code is ugly
as all else.

Incidentally, Qt "doesn't" have this problem:

  auto s =3D QString{
    "but I have heard it works even if you don=E2=80=99t believe in it=E2=
=80=9D};
  s.remove("but ").replace("even", "only").remove(" don't");

(Two caveats there, of course: first, you have to use the overloads that
accept search strings rather than ranges, and second said overloads
replace / remove *ALL* occurrences, so this doesn't have quite the same
semantics, even though this example happens to work.)

> This code has been reviewed by C++ experts world-wide, and published
> (The C++ Programming Language, 4th edition.) Yet, its vulnerability
> to unspecified order of evaluation has been discovered only recently
> by a tool.

That's... astonishing. Granted, we have a significant advantage of
context, but the existence of OOE issues in that is pretty obvious.

That is, I'm surprised the above code is "less obviously troublesome"
than for example 'auto i =3D 1; ++i =3D i++;'

--=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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

On 2016-01-06 00:52, FrankHB1989 wrote:
> =E5=9C=A8 2016=E5=B9=B41=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8A=E5=8D=889:59:44=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A
>> Consider the following program fragment:
>> [...]
>>
>> It uses =E2=80=9Cchaining=E2=80=9D of member function calls, a common st=
andard practice.
>
> How common? I rarely see this style in real code and in the text of the=
=20
> standard besides Clause 27.

I've used method chaining, sometimes extensively (especially for
building DOM documents). What I *haven't* done (AFAIK) is tried to use
the object being acted on in the parameter expressions.

Example:

  // Create header
  html.add(qtDomElement(doc, "head")
             .add(qtDomElement(doc, "meta")
                    .setAttribute("http-equiv", "Content-Type")
                    .setAttribute("content",
                                  "text/xhtml;charset=3DUTF-8"))
             .add(qtDomElement(doc, "title").addText("Example")));

  // Create body
  html.add(qtDomElement(doc, "body")
             .add(qtDomElement(doc, "p", "content")
                    .addText("Hello, world!")));

(Source:
https://github.com/Kitware/qtextensions/blob/master/dom/qtDomElement.h -
it's the example from the documentation, but I've also written "real"
code - which I can't share - that uses the same general form.)

--=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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

On 2016-01-05 21:31, Greg Marr wrote:
> I agree, there is much more code that is OOE safe than has OOE
> problems. In fact, that's part of the problem. Most of your code can
> be fine, but then you hit that one place that has it, and it just
> happens to work with your current compilation environment, and then
> boom, something changes, and it doesn't work any more, and you can't
> find it.
>
> That's the danger in "the starting assumption" being "that the code "works",
> regardless of OOE".  It works only until it doesn't.

I think you are misrepresenting my "starting assumption". To clarify:
most code works "in spite of" undefined OOE because it *is not sensitive
to OOE*. That is, it works for all permissible orders of evaluation, not
just the one that happens to be employed by "the current environment".

> I really do understand the desire for more optimization opportunities.
> How many other optimizations would we be able to make if we relaxed OOE
> requirements in other parts of the standard, and just told people what they
> needed to do or avoid to write proper code?  Would anyone even consider
> proposing them?

Probably not; inertia (i.e. not breaking code that is currently correct)
is a strong counter-argument. In this case, however, inertia is on the
side of leaving OOE unspecified (where it is currently unspecified).

> I think that if the order had been set from
> the
> beginning, no one would now be clamoring for it to be relaxed in order to
> enable these particular optimization potentials.

I... could disagree with that, depending on exactly how you define
"relaxed". Ah...

> I think the route to this particular optimization just needs to be through
> "as-if", with more whole-program knowledge being made available to the
> optimizers.  There are advances in optimization technology fairly regularly
> now, whole program optimization, auto vectorization, auto parallelization.

....yes, this is *exactly* what I've been saying :-). (One of several
things, anyway.) This is the sense in which I could "disagree" with the
above; not that folks would be clamoring for relaxing OOE unilaterally,
but for relaxing it via as-if through better code annotation. (And, as
I've said before, I would have *far* less concern if these mechanisms
were already in place. We need them ten years ago, not *after* making it
harder to optimize via OOE. At the least, I'd feel better if there isn't
a version of the standard that has defined OOE but *not* at least a
reasonable start at such annotations.)

--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bd75cb0141df80528afa5d8
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 6, 2016 at 2:31 AM, Greg Marr <gregmmarr@gmail.com> wrote:

> I think the route to this particular optimization just needs to be through
> "as-if", with more whole-program knowledge being made available to the
> optimizers.  There are advances in optimization technology fairly regularly
> now, whole program optimization, auto vectorization, auto parallelization.
>

The as-if rule restricts optimizers to program transformations that do not
alter the output of the program. Auto-parallelization is a case in point;
there is more scope for parallelization if side effects do not need to
occur in a specific 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bd75cb0141df80528afa5d8
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, Jan 6, 2016 at 2:31 AM, Greg Marr <span dir=3D"ltr">&lt;<a href=3D"mail=
to:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@gmail.com</a>&gt;</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>I think the route to this p=
articular optimization just needs to be through</div><div>&quot;as-if&quot;=
, with more whole-program knowledge being made available to the</div><div>o=
ptimizers.=C2=A0 There are advances in optimization technology fairly regul=
arly</div><div>now, whole program optimization, auto vectorization, auto pa=
rallelization.</div></blockquote><div><br></div><div>The as-if rule restric=
ts optimizers to program transformations that do not alter the output of th=
e program. Auto-parallelization is a case in point; there is more scope for=
 parallelization if side effects do not need to occur in a specific order.<=
br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7bd75cb0141df80528afa5d8--

.

------=_Part_4944_1270862388.1452121542394
Content-Type: multipart/alternative;
 boundary="----=_Part_4945_989974648.1452121542394"

------=_Part_4945_989974648.1452121542394
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 6, 2016 at 2:48:59 PM UTC-5, Edward Catmur wrote:
>
> On Wed, Jan 6, 2016 at 2:31 AM, Greg Marr <greg...@gmail.com <javascript:>
> > wrote:
>
>> I think the route to this particular optimization just needs to be through
>> "as-if", with more whole-program knowledge being made available to the
>> optimizers.  There are advances in optimization technology fairly
>> regularly
>> now, whole program optimization, auto vectorization, auto parallelization.
>>
>
> The as-if rule restricts optimizers to program transformations that do not
> alter the output of the program. Auto-parallelization is a case in point;
> there is more scope for parallelization if side effects do not need to
> occur in a specific order.
>

Those looking for this optimization have already determined that there are
no
side effects that need to occur in a specific order, since if there were,
the
program is already broken.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Wednesday, January 6, 2016 at 2:48:59 PM UTC-5, Edward Catmur wrote:<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">On Wed, Jan 6, 2016 at 2:31 AM, Greg Marr <span dir=3D"ltr=
">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CW=
glYyTAEwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#3=
9;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;"=
>greg...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div>I think the route to this particular optimization just needs to be thr=
ough</div><div>&quot;as-if&quot;, with more whole-program knowledge being m=
ade available to the</div><div>optimizers.=C2=A0 There are advances in opti=
mization technology fairly regularly</div><div>now, whole program optimizat=
ion, auto vectorization, auto parallelization.</div></blockquote><div><br><=
/div><div>The as-if rule restricts optimizers to program transformations th=
at do not alter the output of the program. Auto-parallelization is a case i=
n point; there is more scope for parallelization if side effects do not nee=
d to occur in a specific order.<br></div></div></div></div></blockquote><di=
v><br></div><div>Those looking for this optimization have already determine=
d that there are no</div><div>side effects that need to occur in a specific=
 order, since if there were, the</div><div>program is already broken.</div>=
<div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_4945_989974648.1452121542394--
------=_Part_4944_1270862388.1452121542394--

.

------=_Part_4636_1479707484.1452122703383
Content-Type: multipart/alternative;
 boundary="----=_Part_4637_508513828.1452122703383"

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

On Wednesday, January 6, 2016 at 10:25:28 AM UTC-5, Matthew Woehlke wrote:
>
> On 2016-01-05 20:59, Greg Marr wrote:=20
> > On Tuesday, January 5, 2016 at 10:11:12 AM UTC-5, Matthew Woehlke wrote=
:=20
> >> On 2016-01-04 19:45, Greg Marr wrote:=20
> >>> On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin ":-)" Liber=20
> wrote:=20
>
> > Are you sure that you always avoid OOE errors?=20
>
> Well, no, of course I can't be "sure". That would require some sort of=20
> formal proof, or at least a reliable sanitizer. OTOH, I can't offhand=20
> think of a *single* time that I've been bit by such an error.=20
>

Great, then you're not one of the people that would be helped by this=20
change.
 =20

> >>> I think it is ridiculous to simply tell people not to rely on any=20
> order.=20
> >>>  We know that doesn't work.=20
> >>=20
> >> ...and yet, this contradicts your previous comment.=20
> >=20
> > How so?=20
>
> To quote:=20
>
> >>> We can discourage [relying on a particular OOE] the same way we=20
> >>> discourage naked new.=20
>
> So you say it doesn't work, but also say we should continue to do it=20
> anyway.=20
>

The context for that line:
Someone said that once it's standard, we can't discourage it.
I pointed out that naked new is standard and we still discourage it.
We now also have tools that point out to us when we're doing it.

>>> I think it is ridiculous to simply tell people not to rely on any=20
order.=20
>>>  We know that doesn't work.=20

(adding the emphasis that would be there if this were spoken):
"to *simply* tell people not to rely on any order"

We need to do more than that.
=20

> >> On 2016-01-04 22:28, Greg Marr wrote:=20
> >=20
> > Consider the following program fragment:=20
> >=20
> > void f()=20
> > {=20
> >     std::string s =3D =E2=80=9Cbut I have heard it works even if you do=
n=E2=80=99t believe=20
> in=20
> > it=E2=80=9D;=20
> >     s.replace(0, 4, =E2=80=9C=E2=80=9D).replace(s.find(=E2=80=9Ceven=E2=
=80=9D), 4,=20
> =E2=80=9Conly=E2=80=9D).replace(s.find(=E2=80=9C=20
> > don=E2=80=99t=E2=80=9D), 6, =E2=80=9C=E2=80=9D);=20
> >     assert(s =3D=3D =E2=80=9CI have heard it works only if you believe =
in it=E2=80=9D);=20
> > }=20
>
> Oh. Yes, I remember that now. Personally, I... think that code is ugly=20
> as all else.=20
>
=20
Had you seen that code in the book?  Did you think it was ugly then?
If so, then great.  Other people obviously didn't.

Incidentally, Qt "doesn't" have this problem:=20
>   auto s =3D QString{=20
>
=20

>     "but I have heard it works even if you don=E2=80=99t believe in it=E2=
=80=9D};=20
>   s.remove("but ").replace("even", "only").remove(" don't");=20
>
> (Two caveats there, of course: first, you have to use the overloads that=
=20
> accept search strings rather than ranges, and second said overloads=20
> replace / remove *ALL* occurrences, so this doesn't have quite the same=
=20
> semantics, even though this example happens to work.)=20
>

Well, yes, there is no order of evaluation issue here because the standard
says that there is no undefined order of evaluation here.  You can't call
replace() before the first remove() returns, and there are no function call=
s
or other operations in any of the parameters, other than possibly creation
of temporary QString objects around the string literals, and that doesn't
introduce the error in this particular case.

However, as you said, it's not the same semantic, and you can still make
the exact same mistake in Qt:

s.replace(0, 4, =E2=80=9C=E2=80=9D).replace(s.indexOf(=E2=80=9Ceven=E2=80=
=9D), 4,=20
=E2=80=9Conly=E2=80=9D).replace(s.indexOf(=E2=80=9C=20
> don=E2=80=99t=E2=80=9D), 6, =E2=80=9C=E2=80=9D);

> This code has been reviewed by C++ experts world-wide, and published=20
> > (The C++ Programming Language, 4th edition.) Yet, its vulnerability=20
> > to unspecified order of evaluation has been discovered only recently=20
> > by a tool.=20
>
> That's... astonishing. Granted, we have a significant advantage of=20
> context, but the existence of OOE issues in that is pretty obvious.=20
>

Since you know they're there, then it is pretty obvious.  Who knows if it
would have been obvious if we didn't know it was there.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">On Wednesday, January 6, 2016 at 10:25:28 AM UTC-5, Matthe=
w Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-01-05 =
20:59, Greg Marr wrote:
<br>&gt; On Tuesday, January 5, 2016 at 10:11:12 AM UTC-5, Matthew Woehlke =
wrote:
<br>&gt;&gt; On 2016-01-04 19:45, Greg Marr wrote:=20
<br>&gt;&gt;&gt; On Monday, January 4, 2016 at 6:05:33 PM UTC-5, Nevin &quo=
t;:-)&quot; Liber wrote:=20
<br><br>&gt; Are you sure that you always avoid OOE errors?
<br>
<br>Well, no, of course I can&#39;t be &quot;sure&quot;. That would require=
 some sort of
<br>formal proof, or at least a reliable sanitizer. OTOH, I can&#39;t offha=
nd
<br>think of a *single* time that I&#39;ve been bit by such an error.
<br></blockquote><div><br></div><div>Great, then you&#39;re not one of the =
people that would be helped by this change.</div><div>=C2=A0=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">&gt;&gt;&gt; I think it is ridicu=
lous to simply tell people not to rely on any order.=20
<br>&gt;&gt;&gt; =C2=A0We know that doesn&#39;t work.=20
<br>&gt;&gt;
<br>&gt;&gt; ...and yet, this contradicts your previous comment.=20
<br>&gt;=20
<br>&gt; How so?
<br>
<br>To quote:
<br>
<br>&gt;&gt;&gt; We can discourage [relying on a particular OOE] the same w=
ay we=20
<br>&gt;&gt;&gt; discourage naked new.
<br>
<br>So you say it doesn&#39;t work, but also say we should continue to do i=
t anyway.
<br></blockquote><div><br></div><div>The context for that line:</div><div>S=
omeone said that once it&#39;s standard, we can&#39;t discourage it.</div><=
div>I pointed out that naked new is standard and we still discourage it.</d=
iv><div><div>We now also have tools that point out to us when we&#39;re doi=
ng it.<br></div></div><div><br></div><div>&gt;&gt;&gt; I think it is ridicu=
lous to simply tell people not to rely on any order.=C2=A0<br>&gt;&gt;&gt; =
=C2=A0We know that doesn&#39;t work.=C2=A0<br></div><div><br></div><div>(ad=
ding the emphasis that would be there if this were spoken):</div><div>&quot=
;to *simply* tell people not to rely on any order&quot;</div><div><br></div=
><div>We need to do more than that.<br></div><div>=C2=A0<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">&gt;&gt; On 2016-01-04 22:28, Greg Marr=
 wrote:=20
<br>&gt;=20
<br>&gt; Consider the following program fragment:
<br>&gt;=20
<br>&gt; void f()
<br>&gt; {
<br>&gt; =C2=A0 =C2=A0 std::string s =3D =E2=80=9Cbut I have heard it works=
 even if you don=E2=80=99t believe in=20
<br>&gt; it=E2=80=9D;
<br>&gt; =C2=A0 =C2=A0 s.replace(0, 4, =E2=80=9C=E2=80=9D).replace(s.find(=
=E2=80=9Ceven=E2=80=9D), 4, =E2=80=9Conly=E2=80=9D).replace(s.find(=E2=80=
=9C=20
<br>&gt; don=E2=80=99t=E2=80=9D), 6, =E2=80=9C=E2=80=9D);
<br>&gt; =C2=A0 =C2=A0 assert(s =3D=3D =E2=80=9CI have heard it works only =
if you believe in it=E2=80=9D);
<br>&gt; }
<br>
<br>Oh. Yes, I remember that now. Personally, I... think that code is ugly
<br>as all else.
<br></blockquote><div>=C2=A0</div><div>Had you seen that code in the book? =
=C2=A0Did you think it was ugly then?</div><div>If so, then great. =C2=A0Ot=
her people obviously didn&#39;t.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">
Incidentally, Qt &quot;doesn&#39;t&quot; have this problem:=C2=A0<br>=C2=A0=
 auto s =3D QString{
<br></blockquote><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;">=C2=A0 =C2=A0 &quot;but I have heard it works even if you don=E2=80=
=99t believe in it=E2=80=9D};
<br>=C2=A0 s.remove(&quot;but &quot;).replace(&quot;even&quot;, &quot;only&=
quot;).remove(&quot; don&#39;t&quot;);
<br>
<br>(Two caveats there, of course: first, you have to use the overloads tha=
t
<br>accept search strings rather than ranges, and second said overloads
<br>replace / remove *ALL* occurrences, so this doesn&#39;t have quite the =
same
<br>semantics, even though this example happens to work.)
<br></blockquote><div><br></div><div>Well, yes, there is no order of evalua=
tion issue here because the standard</div><div>says that there is no undefi=
ned order of evaluation here. =C2=A0You can&#39;t call</div><div>replace() =
before the first remove() returns, and there are no function calls</div><di=
v>or other operations in any of the parameters, other than possibly creatio=
n</div><div>of temporary QString objects around the string literals, and th=
at doesn&#39;t</div><div>introduce the error in this particular case.</div>=
<div><br></div><div>However, as you said, it&#39;s not the same semantic, a=
nd you can still make</div><div>the exact same mistake in Qt:<br></div><div=
><br></div><div>s.replace(0, 4, =E2=80=9C=E2=80=9D).replace(s.indexOf(=E2=
=80=9Ceven=E2=80=9D), 4, =E2=80=9Conly=E2=80=9D).replace(s.indexOf(=E2=80=
=9C=C2=A0<br>&gt; don=E2=80=99t=E2=80=9D), 6, =E2=80=9C=E2=80=9D);<br></div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; This code=
 has been reviewed by C++ experts world-wide, and published
<br>&gt; (The C++ Programming Language, 4th edition.) Yet, its vulnerabilit=
y
<br>&gt; to unspecified order of evaluation has been discovered only recent=
ly
<br>&gt; by a tool.
<br>
<br>That&#39;s... astonishing. Granted, we have a significant advantage of
<br>context, but the existence of OOE issues in that is pretty obvious.
<br></blockquote><div><br></div><div>Since you know they&#39;re there, then=
 it is pretty obvious. =C2=A0Who knows if it</div><div>would have been obvi=
ous if we didn&#39;t know it was there.</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_4637_508513828.1452122703383--
------=_Part_4636_1479707484.1452122703383--

.

--047d7bd75cb04c36670528b38c73
Content-Type: text/plain; charset=UTF-8

On 6 Jan 2016 23:05, "Greg Marr" <gregmmarr@gmail.com> wrote:
>
> On Wednesday, January 6, 2016 at 2:48:59 PM UTC-5, Edward Catmur wrote:
>>
>> On Wed, Jan 6, 2016 at 2:31 AM, Greg Marr <greg...@gmail.com> wrote:
>>>
>>> I think the route to this particular optimization just needs to be
through
>>> "as-if", with more whole-program knowledge being made available to the
>>> optimizers.  There are advances in optimization technology fairly
regularly
>>> now, whole program optimization, auto vectorization, auto
parallelization.
>>
>>
>> The as-if rule restricts optimizers to program transformations that do
not alter the output of the program. Auto-parallelization is a case in
point; there is more scope for parallelization if side effects do not need
to occur in a specific order.
>
>
> Those looking for this optimization have already determined that there
are no
> side effects that need to occur in a specific order, since if there were,
the
> program is already broken.

Right, but the as-if rule doesn't know that. All it sees is side effects,
and if the Standard is changed to require them to occur in a specific order
it has to respect that, even if the author is fine with them occurring in
any 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<p dir=3D"ltr"><br>
On 6 Jan 2016 23:05, &quot;Greg Marr&quot; &lt;<a href=3D"mailto:gregmmarr@=
gmail.com">gregmmarr@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wednesday, January 6, 2016 at 2:48:59 PM UTC-5, Edward Catmur wrote=
:<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Jan 6, 2016 at 2:31 AM, Greg Marr &lt;<a href=3D"mailto:gr=
eg...@gmail.com">greg...@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I think the route to this particular optimization just needs t=
o be through<br>
&gt;&gt;&gt; &quot;as-if&quot;, with more whole-program knowledge being mad=
e available to the<br>
&gt;&gt;&gt; optimizers.=C2=A0 There are advances in optimization technolog=
y fairly regularly<br>
&gt;&gt;&gt; now, whole program optimization, auto vectorization, auto para=
llelization.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; The as-if rule restricts optimizers to program transformations tha=
t do not alter the output of the program. Auto-parallelization is a case in=
 point; there is more scope for parallelization if side effects do not need=
 to occur in a specific order.<br>
&gt;<br>
&gt;<br>
&gt; Those looking for this optimization have already determined that there=
 are no<br>
&gt; side effects that need to occur in a specific order, since if there we=
re, the<br>
&gt; program is already broken.</p>
<p dir=3D"ltr">Right, but the as-if rule doesn&#39;t know that. All it sees=
 is side effects, and if the Standard is changed to require them to occur i=
n a specific order it has to respect that, even if the author is fine with =
them occurring in any order. </p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7bd75cb04c36670528b38c73--

.

------=_Part_5063_1898992673.1452156418051
Content-Type: multipart/alternative;
 boundary="----=_Part_5064_585977700.1452156418052"

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



=E5=9C=A8 2016=E5=B9=B41=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8B=E5=8D=8811:36:46=EF=BC=8CMatthew Woehlke=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On 2016-01-06 00:52, FrankHB1989 wrote:=20
> > =E5=9C=A8 2016=E5=B9=B41=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8A=E5=8D=889:59:44=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A=
=20
> >> Consider the following program fragment:=20
> >> [...]=20
> >>=20
> >> It uses =E2=80=9Cchaining=E2=80=9D of member function calls, a common =
standard=20
> practice.=20
> >=20
> > How common? I rarely see this style in real code and in the text of the=
=20
> > standard besides Clause 27.=20
>
> I've used method chaining, sometimes extensively (especially for=20
> building DOM documents). What I *haven't* done (AFAIK) is tried to use=20
> the object being acted on in the parameter expressions.=20
>
> Example:=20
>
>   // Create header=20
>   html.add(qtDomElement(doc, "head")=20
>              .add(qtDomElement(doc, "meta")=20
>                     .setAttribute("http-equiv", "Content-Type")=20
>                     .setAttribute("content",=20
>                                   "text/xhtml;charset=3DUTF-8"))=20
>              .add(qtDomElement(doc, "title").addText("Example")));=20
>
>   // Create body=20
>   html.add(qtDomElement(doc, "body")=20
>              .add(qtDomElement(doc, "p", "content")=20
>                     .addText("Hello, world!")));=20
>
> (Source:=20
> https://github.com/Kitware/qtextensions/blob/master/dom/qtDomElement.h -=
=20
> it's the example from the documentation, but I've also written "real"=20
> code - which I can't share - that uses the same general form.)=20
>
> --=20
> Matthew=20
>
> I know there *exists *real code in this style, but I don't see it often.

The way to constructing structured data in this style is plausible, but=20
most time it is not the better solution in technical perspective. There are=
=20
several reasons to not use here:

   1. The general defects for this style are remained.
   2. The task itself does not require explicit order dependency,=20
   essentially. The code has some extra semantics noise (as it have somethi=
ng=20
   not required actually, done with significance like other vital meaning),=
=20
   though not very confusing here.
   3. There are replacements without those imperfection. To be more=20
   declarative, i.e. using features to contain the data (e.g. user-defined=
=20
   literal and nested initializers, though the latter is also somewhat=20
   questionable on evaluation order) as arguments of one transformation met=
hod=20
   call, rather than a potentially long statement with each verb per=20
   insertion, should be a clearer approach. It is also friendly to introduc=
ing=20
   some explicit middle levels (for optimization, debug, logging, etc).
  =20
Note that I am not saying you should never use this style. It may be serve=
=20
to simple instances of tasks well. However, to encourage this style=20
broadly, especially where the more superior (more convenient, clearer and=
=20
not so error-prone) ways already exist, does not convince me a good=20
practice.


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2016=E5=B9=B41=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=89 UTC+8=E4=B8=8B=E5=8D=8811:36:46=EF=BC=8CMatthew Woehlke=E5=86=99=E9=81=
=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-01-06 00:5=
2, FrankHB1989 wrote:
<br>&gt; =E5=9C=A8 2016=E5=B9=B41=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=89 UTC+8=E4=B8=8A=E5=8D=889:59:44=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=
=EF=BC=9A
<br>&gt;&gt; Consider the following program fragment:
<br>&gt;&gt; [...]
<br>&gt;&gt;
<br>&gt;&gt; It uses =E2=80=9Cchaining=E2=80=9D of member function calls, a=
 common standard practice.
<br>&gt;
<br>&gt; How common? I rarely see this style in real code and in the text o=
f the=20
<br>&gt; standard besides Clause 27.
<br>
<br>I&#39;ve used method chaining, sometimes extensively (especially for
<br>building DOM documents). What I *haven&#39;t* done (AFAIK) is tried to =
use
<br>the object being acted on in the parameter expressions.
<br>
<br>Example:
<br>
<br>=C2=A0 // Create header
<br>=C2=A0 html.add(qtDomElement(doc, &quot;head&quot;)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.add(qtDomElement(doc, =
&quot;meta&quot;)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .=
setAttribute(&quot;http-equiv&quot;, &quot;Content-Type&quot;)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .=
setAttribute(&quot;content&quot;,
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quot;text/xhtml;charset=
=3DUTF-8&quot;))
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.add(qtDomElement(doc, =
&quot;title&quot;).addText(&quot;Example&quot;)));
<br>
<br>=C2=A0 // Create body
<br>=C2=A0 html.add(qtDomElement(doc, &quot;body&quot;)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.add(qtDomElement(doc, =
&quot;p&quot;, &quot;content&quot;)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .=
addText(&quot;Hello, world!&quot;)));
<br>
<br>(Source:
<br><a href=3D"https://github.com/Kitware/qtextensions/blob/master/dom/qtDo=
mElement.h" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FKitware%2Fqte=
xtensions%2Fblob%2Fmaster%2Fdom%2FqtDomElement.h\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGmau8T9M3gPlPQlmlx2hSNLukhkw&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FKitware=
%2Fqtextensions%2Fblob%2Fmaster%2Fdom%2FqtDomElement.h\46sa\75D\46sntz\0751=
\46usg\75AFQjCNGmau8T9M3gPlPQlmlx2hSNLukhkw&#39;;return true;">https://gith=
ub.com/Kitware/<wbr>qtextensions/blob/master/dom/<wbr>qtDomElement.h</a> -
<br>it&#39;s the example from the documentation, but I&#39;ve also written =
&quot;real&quot;
<br>code - which I can&#39;t share - that uses the same general form.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div>I know there <i>exists </i>real code in this style, b=
ut I don&#39;t see it often.<br><br>The way to constructing structured data=
 in this style is plausible, but most time it is not the better solution in=
 technical perspective. There are several reasons to not use here:<br><ol><=
li>The general defects for this style are remained.</li><li>The task itself=
 does not require explicit order dependency, essentially. The code has some=
 extra semantics noise (as it have something not required actually, done wi=
th significance like other vital meaning), though not very confusing here.<=
/li><li>There are replacements without those imperfection. To be more decla=
rative, i.e. using features to contain the data (e.g. user-defined literal =
and nested initializers, though the latter is also somewhat questionable on=
 evaluation order) as arguments of one transformation method call, rather t=
han a potentially long statement with each verb per insertion, should be a =
clearer approach. It is also friendly to introducing some explicit middle l=
evels (for optimization, debug, logging, etc).<br></li></ol>Note that I am =
not saying you should never use this style. It may be serve to simple insta=
nces of tasks well. However, to encourage this style broadly, especially wh=
ere the more superior (more convenient, clearer and not so error-prone) way=
s already exist, does not convince me a good practice.<br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_5064_585977700.1452156418052--
------=_Part_5063_1898992673.1452156418051--

.

------=_Part_5973_2059788511.1452191442296
Content-Type: multipart/alternative;
 boundary="----=_Part_5974_360451942.1452191442296"

------=_Part_5974_360451942.1452191442296
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 6, 2016 at 7:28:23 PM UTC-5, Edward Catmur wrote:
>
> On 6 Jan 2016 23:05, "Greg Marr" <greg...@gmail.com <javascript:>> wrote:
> >
> > On Wednesday, January 6, 2016 at 2:48:59 PM UTC-5, Edward Catmur wrote:
> >>
> >> On Wed, Jan 6, 2016 at 2:31 AM, Greg Marr <greg...@gmail.com> wrote:
> >>>
> >>> I think the route to this particular optimization just needs to be
> through
> >>> "as-if", with more whole-program knowledge being made available to the
> >>> optimizers.  There are advances in optimization technology fairly
> regularly
> >>> now, whole program optimization, auto vectorization, auto
> parallelization.
> >>
> >>
> >> The as-if rule restricts optimizers to program transformations that do
> not alter the output of the program. Auto-parallelization is a case in
> point; there is more scope for parallelization if side effects do not need
> to occur in a specific order.
> >
> >
> > Those looking for this optimization have already determined that there
> are no
> > side effects that need to occur in a specific order, since if there
> were, the
> > program is already broken.
>
> Right, but the as-if rule doesn't know that. All it sees is side effects,
> and if the Standard is changed to require them to occur in a specific order
> it has to respect that, even if the author is fine with them occurring in
> any order.
>

Not if changing the order doesn't change the observable behavior of the
program.
If it does, then the program is currently broken.
If it doesn't, then a future optimizer can reorder them however it wants.
The hard part there is recognizing when that is safe, which is why Matthew
wants the ability to tell the optimizer that he knows it's safe.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Wednesday, January 6, 2016 at 7:28:23 PM UTC-5, Edward Catmur wrote:<blo=
ckquote 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 6 Jan 2016 23:05=
, &quot;Greg Marr&quot; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"kFPNo2PPEwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">greg...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wednesday, January 6, 2016 at 2:48:59 PM UTC-5, Edward Catmur wrote=
:<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Jan 6, 2016 at 2:31 AM, Greg Marr &lt;<a>greg...@gmail.com=
</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I think the route to this particular optimization just needs t=
o be through<br>
&gt;&gt;&gt; &quot;as-if&quot;, with more whole-program knowledge being mad=
e available to the<br>
&gt;&gt;&gt; optimizers.=C2=A0 There are advances in optimization technolog=
y fairly regularly<br>
&gt;&gt;&gt; now, whole program optimization, auto vectorization, auto para=
llelization.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; The as-if rule restricts optimizers to program transformations tha=
t do not alter the output of the program. Auto-parallelization is a case in=
 point; there is more scope for parallelization if side effects do not need=
 to occur in a specific order.<br>
&gt;<br>
&gt;<br>
&gt; Those looking for this optimization have already determined that there=
 are no<br>
&gt; side effects that need to occur in a specific order, since if there we=
re, the<br>
&gt; program is already broken.</p>
<p dir=3D"ltr">Right, but the as-if rule doesn&#39;t know that. All it sees=
 is side effects, and if the Standard is changed to require them to occur i=
n a specific order it has to respect that, even if the author is fine with =
them occurring in any order.</p></blockquote><div><br></div><div>Not if cha=
nging the order doesn&#39;t change the observable behavior of the program.<=
/div><div>If it does, then the program is currently broken.</div><div>If it=
 doesn&#39;t, then a future optimizer can reorder them however it wants.</d=
iv><div>The hard part there is recognizing when that is safe, which is why =
Matthew</div><div>wants the ability to tell the optimizer that he knows it&=
#39;s safe.</div><div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_5974_360451942.1452191442296--
------=_Part_5973_2059788511.1452191442296--

.

--047d7bea43fc691a580528c40645
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 7, 2016 at 6:30 PM, Greg Marr <gregmmarr@gmail.com> wrote:

> On Wednesday, January 6, 2016 at 7:28:23 PM UTC-5, Edward Catmur wrote:
>>
>> On 6 Jan 2016 23:05, "Greg Marr" <greg...@gmail.com> wrote:
>> >
>> > On Wednesday, January 6, 2016 at 2:48:59 PM UTC-5, Edward Catmur wrote:
>> >>
>> >> On Wed, Jan 6, 2016 at 2:31 AM, Greg Marr <greg...@gmail.com> wrote:
>> >>>
>> >>> I think the route to this particular optimization just needs to be
>> through
>> >>> "as-if", with more whole-program knowledge being made available to the
>> >>> optimizers.  There are advances in optimization technology fairly
>> regularly
>> >>> now, whole program optimization, auto vectorization, auto
>> parallelization.
>> >>
>> >>
>> >> The as-if rule restricts optimizers to program transformations that do
>> not alter the output of the program. Auto-parallelization is a case in
>> point; there is more scope for parallelization if side effects do not need
>> to occur in a specific order.
>> >
>> >
>> > Those looking for this optimization have already determined that there
>> are no
>> > side effects that need to occur in a specific order, since if there
>> were, the
>> > program is already broken.
>>
>> Right, but the as-if rule doesn't know that. All it sees is side effects,
>> and if the Standard is changed to require them to occur in a specific order
>> it has to respect that, even if the author is fine with them occurring in
>> any order.
>>
>
> Not if changing the order doesn't change the observable behavior of the
> program.
> If it does, then the program is currently broken.
> If it doesn't, then a future optimizer can reorder them however it wants.
> The hard part there is recognizing when that is safe, which is why Matthew
> wants the ability to tell the optimizer that he knows it's safe.
>


That doesn't necessarily mean the program is broken; the alternative
behavior could be equally acceptable. This is commonly the case for
multithreaded programs. (This also makes the task of a sanitizer harder;
just because a program transformation affects the output doesn't
necessarily mean it's 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bea43fc691a580528c40645
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, Jan 7, 2016 at 6:30 PM, Greg Marr <span dir=3D"ltr">&lt;<a href=3D"mail=
to:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">On Wednesday, January 6, 2016 at=
 7:28:23 PM UTC-5, Edward Catmur wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><p dir=3D"ltr">On 6 Jan 2016 23:05, &quot;Greg Marr&quot; &lt;<a rel=3D=
"nofollow">greg...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wednesday, January 6, 2016 at 2:48:59 PM UTC-5, Edward Catmur wrote=
:<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Jan 6, 2016 at 2:31 AM, Greg Marr &lt;<a>greg...@gmail.com=
</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I think the route to this particular optimization just needs t=
o be through<br>
&gt;&gt;&gt; &quot;as-if&quot;, with more whole-program knowledge being mad=
e available to the<br>
&gt;&gt;&gt; optimizers.=C2=A0 There are advances in optimization technolog=
y fairly regularly<br>
&gt;&gt;&gt; now, whole program optimization, auto vectorization, auto para=
llelization.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; The as-if rule restricts optimizers to program transformations tha=
t do not alter the output of the program. Auto-parallelization is a case in=
 point; there is more scope for parallelization if side effects do not need=
 to occur in a specific order.<br>
&gt;<br>
&gt;<br>
&gt; Those looking for this optimization have already determined that there=
 are no<br>
&gt; side effects that need to occur in a specific order, since if there we=
re, the<br>
&gt; program is already broken.</p>
<p dir=3D"ltr">Right, but the as-if rule doesn&#39;t know that. All it sees=
 is side effects, and if the Standard is changed to require them to occur i=
n a specific order it has to respect that, even if the author is fine with =
them occurring in any order.</p></blockquote><div><br></div><div>Not if cha=
nging the order doesn&#39;t change the observable behavior of the program.<=
/div><div>If it does, then the program is currently broken.</div><div>If it=
 doesn&#39;t, then a future optimizer can reorder them however it wants.</d=
iv><div>The hard part there is recognizing when that is safe, which is why =
Matthew</div><div>wants the ability to tell the optimizer that he knows it&=
#39;s safe.</div></blockquote><div><br></div><div>=C2=A0</div><div>That doe=
sn&#39;t necessarily mean the program is broken; the alternative behavior c=
ould be equally acceptable. This is commonly the case for multithreaded pro=
grams. (This also makes the task of a sanitizer harder; just because a prog=
ram transformation affects the output doesn&#39;t necessarily mean it&#39;s=
 wrong.)</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7bea43fc691a580528c40645--

.

--047d7bdca44067ab2f0528cf707e
Content-Type: text/plain; charset=UTF-8

On 6 Jan 2016 23:25, "Greg Marr" <gregmmarr@gmail.com> wrote:
>
> The context for that line:
> Someone said that once it's standard, we can't discourage it.
> I pointed out that naked new is standard and we still discourage it.
> We now also have tools that point out to us when we're doing it.

We replaced naked new with smart pointers. What we didn't do is attempt to
patch it up by mandating garbage collection.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bdca44067ab2f0528cf707e
Content-Type: text/html; charset=UTF-8

<p dir="ltr"><br>
On 6 Jan 2016 23:25, &quot;Greg Marr&quot; &lt;<a href="mailto:gregmmarr@gmail.com">gregmmarr@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; The context for that line:<br>
&gt; Someone said that once it&#39;s standard, we can&#39;t discourage it.<br>
&gt; I pointed out that naked new is standard and we still discourage it.<br>
&gt; We now also have tools that point out to us when we&#39;re doing it.<br></p>
<p dir="ltr">We replaced naked new with smart pointers. What we didn&#39;t do is attempt to patch it up by mandating garbage collection.</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="https://groups.google.com/a/isocpp.org/group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--047d7bdca44067ab2f0528cf707e--

.

------=_Part_1574_52796884.1452280422013
Content-Type: multipart/alternative;
 boundary="----=_Part_1575_2089937867.1452280422014"

------=_Part_1575_2089937867.1452280422014
Content-Type: text/plain; charset=UTF-8

On Friday, January 8, 2016 at 4:44:54 AM UTC-5, Edward Catmur wrote:
>
>
> On 6 Jan 2016 23:25, "Greg Marr" <greg...@gmail.com <javascript:>> wrote:
> >
> > The context for that line:
> > Someone said that once it's standard, we can't discourage it.
> > I pointed out that naked new is standard and we still discourage it.
> > We now also have tools that point out to us when we're doing it.
>
> We replaced naked new with smart pointers. What we didn't do is attempt to
> patch it up by mandating garbage collection.
>

What does that have to do with the ability to discourage things which are
standard-conforming?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Friday, January 8, 2016 at 4:44:54 AM UTC-5, 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;"><p dir=3D"ltr"><br>
On 6 Jan 2016 23:25, &quot;Greg Marr&quot; &lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"IMEVuFY8FAAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;">greg...@gmail.com</a>&gt; wrote:<=
br>
&gt;<br>
&gt; The context for that line:<br>
&gt; Someone said that once it&#39;s standard, we can&#39;t discourage it.<=
br>
&gt; I pointed out that naked new is standard and we still discourage it.<b=
r>
&gt; We now also have tools that point out to us when we&#39;re doing it.<b=
r></p>
<p dir=3D"ltr">We replaced naked new with smart pointers. What we didn&#39;=
t do is attempt to patch it up by mandating garbage collection.</p></blockq=
uote><div><br></div><div>What does that have to do with the ability to disc=
ourage things which are standard-conforming?</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1575_2089937867.1452280422014--
------=_Part_1574_52796884.1452280422013--

.

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

On 8 Jan 2016 19:13, "Greg Marr" <gregmmarr@gmail.com> wrote:
>
> On Friday, January 8, 2016 at 4:44:54 AM UTC-5, Edward Catmur wrote:
>>
>>
>> On 6 Jan 2016 23:25, "Greg Marr" <greg...@gmail.com> wrote:
>> >
>> > The context for that line:
>> > Someone said that once it's standard, we can't discourage it.
>> > I pointed out that naked new is standard and we still discourage it.
>> > We now also have tools that point out to us when we're doing it.
>>
>> We replaced naked new with smart pointers. What we didn't do is attempt
to patch it up by mandating garbage collection.
>
>
> What does that have to do with the ability to discourage things which are
standard-conforming?

It demonstrates that the two cases are not entirely parallel. Would we have
been able to discourage naked new if it had been made "safe" by mandating
garbage collection?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1140f750cd066a0528d80af1
Content-Type: text/html; charset=UTF-8

<p dir="ltr"><br>
On 8 Jan 2016 19:13, &quot;Greg Marr&quot; &lt;<a href="mailto:gregmmarr@gmail.com">gregmmarr@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Friday, January 8, 2016 at 4:44:54 AM UTC-5, Edward Catmur wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 6 Jan 2016 23:25, &quot;Greg Marr&quot; &lt;<a href="mailto:greg...@gmail.com">greg...@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The context for that line:<br>
&gt;&gt; &gt; Someone said that once it&#39;s standard, we can&#39;t discourage it.<br>
&gt;&gt; &gt; I pointed out that naked new is standard and we still discourage it.<br>
&gt;&gt; &gt; We now also have tools that point out to us when we&#39;re doing it.<br>
&gt;&gt;<br>
&gt;&gt; We replaced naked new with smart pointers. What we didn&#39;t do is attempt to patch it up by mandating garbage collection.<br>
&gt;<br>
&gt;<br>
&gt; What does that have to do with the ability to discourage things which are standard-conforming?<br></p>
<p dir="ltr">It demonstrates that the two cases are not entirely parallel. Would we have been able to discourage naked new if it had been made &quot;safe&quot; by mandating garbage collection? </p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="https://groups.google.com/a/isocpp.org/group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--001a1140f750cd066a0528d80af1--

.

------=_Part_1610_706236352.1452286106652
Content-Type: multipart/alternative;
 boundary="----=_Part_1611_1702114489.1452286106652"

------=_Part_1611_1702114489.1452286106652
Content-Type: text/plain; charset=UTF-8

On Friday, January 8, 2016 at 3:00:44 PM UTC-5, Edward Catmur wrote:
>
>
> On 8 Jan 2016 19:13, "Greg Marr" <greg...@gmail.com <javascript:>> wrote:
> >
> > On Friday, January 8, 2016 at 4:44:54 AM UTC-5, Edward Catmur wrote:
> >>
> >>
> >> On 6 Jan 2016 23:25, "Greg Marr" <greg...@gmail.com> wrote:
> >> >
> >> > The context for that line:
> >> > Someone said that once it's standard, we can't discourage it.
> >> > I pointed out that naked new is standard and we still discourage it.
> >> > We now also have tools that point out to us when we're doing it.
> >>
> >> We replaced naked new with smart pointers. What we didn't do is attempt
> to patch it up by mandating garbage collection.
> >
> >
> > What does that have to do with the ability to discourage things which
> are standard-conforming?
>
> It demonstrates that the two cases are not entirely parallel. Would we
> have been able to discourage naked new if it had been made "safe" by
> mandating garbage collection?
>

Yes.  I'm not making value judgments in that statement about
whether or not any particular individual should do such a thing,
just saying that the fact that it is allowed by the standard doesn't
mean that we can't discourage 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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Friday, January 8, 2016 at 3:00:44 PM UTC-5, Edward Catmur wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"><br>
On 8 Jan 2016 19:13, &quot;Greg Marr&quot; &lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"3XZ-3vFdFAAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;">greg...@gmail.com</a>&gt; wrote:<=
br>
&gt;<br>
&gt; On Friday, January 8, 2016 at 4:44:54 AM UTC-5, Edward Catmur wrote:<b=
r>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 6 Jan 2016 23:25, &quot;Greg Marr&quot; &lt;<a>greg...@gmail.co=
m</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The context for that line:<br>
&gt;&gt; &gt; Someone said that once it&#39;s standard, we can&#39;t discou=
rage it.<br>
&gt;&gt; &gt; I pointed out that naked new is standard and we still discour=
age it.<br>
&gt;&gt; &gt; We now also have tools that point out to us when we&#39;re do=
ing it.<br>
&gt;&gt;<br>
&gt;&gt; We replaced naked new with smart pointers. What we didn&#39;t do i=
s attempt to patch it up by mandating garbage collection.<br>
&gt;<br>
&gt;<br>
&gt; What does that have to do with the ability to discourage things which =
are standard-conforming?<br></p>
<p dir=3D"ltr">It demonstrates that the two cases are not entirely parallel=
.. Would we have been able to discourage naked new if it had been made &quot=
;safe&quot; by mandating garbage collection?</p></blockquote><div><br></div=
><div>Yes. =C2=A0I&#39;m not making value judgments in that statement about=
</div><div>whether or not any particular individual should do such a thing,=
</div><div>just saying that the fact that it is allowed by the standard doe=
sn&#39;t</div><div>mean that we can&#39;t discourage it.</div><div><br></di=
v>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1611_1702114489.1452286106652--
------=_Part_1610_706236352.1452286106652--

.

--089e01538e309710680528d9fb4e
Content-Type: text/plain; charset=UTF-8

On 8 Jan 2016 20:48, "Greg Marr" <gregmmarr@gmail.com> wrote:
>
> On Friday, January 8, 2016 at 3:00:44 PM UTC-5, Edward Catmur wrote:
>>
>>
>> On 8 Jan 2016 19:13, "Greg Marr" <greg...@gmail.com> wrote:
>> >
>> > On Friday, January 8, 2016 at 4:44:54 AM UTC-5, Edward Catmur wrote:
>> >>
>> >>
>> >> On 6 Jan 2016 23:25, "Greg Marr" <greg...@gmail.com> wrote:
>> >> >
>> >> > The context for that line:
>> >> > Someone said that once it's standard, we can't discourage it.
>> >> > I pointed out that naked new is standard and we still discourage it.
>> >> > We now also have tools that point out to us when we're doing it.
>> >>
>> >> We replaced naked new with smart pointers. What we didn't do is
attempt to patch it up by mandating garbage collection.
>> >
>> >
>> > What does that have to do with the ability to discourage things which
are standard-conforming?
>>
>> It demonstrates that the two cases are not entirely parallel. Would we
have been able to discourage naked new if it had been made "safe" by
mandating garbage collection?
>
>
> Yes.  I'm not making value judgments in that statement about
> whether or not any particular individual should do such a thing,
> just saying that the fact that it is allowed by the standard doesn't
> mean that we can't discourage it.

It wouldn't literally be impossible to discourage it, but it would be
politically difficult if the standard were to be seen to condone it. I'm
not aware of any case where the standard was changed to favor a discouraged
practice.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<p dir=3D"ltr"><br>
On 8 Jan 2016 20:48, &quot;Greg Marr&quot; &lt;<a href=3D"mailto:gregmmarr@=
gmail.com">gregmmarr@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Friday, January 8, 2016 at 3:00:44 PM UTC-5, Edward Catmur wrote:<b=
r>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 8 Jan 2016 19:13, &quot;Greg Marr&quot; &lt;<a href=3D"mailto:g=
reg...@gmail.com">greg...@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Friday, January 8, 2016 at 4:44:54 AM UTC-5, Edward Catmur=
 wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On 6 Jan 2016 23:25, &quot;Greg Marr&quot; &lt;<a href=3D=
"mailto:greg...@gmail.com">greg...@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; The context for that line:<br>
&gt;&gt; &gt;&gt; &gt; Someone said that once it&#39;s standard, we can&#39=
;t discourage it.<br>
&gt;&gt; &gt;&gt; &gt; I pointed out that naked new is standard and we stil=
l discourage it.<br>
&gt;&gt; &gt;&gt; &gt; We now also have tools that point out to us when we&=
#39;re doing it.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; We replaced naked new with smart pointers. What we didn&#=
39;t do is attempt to patch it up by mandating garbage collection.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; What does that have to do with the ability to discourage thin=
gs which are standard-conforming?<br>
&gt;&gt;<br>
&gt;&gt; It demonstrates that the two cases are not entirely parallel. Woul=
d we have been able to discourage naked new if it had been made &quot;safe&=
quot; by mandating garbage collection?<br>
&gt;<br>
&gt;<br>
&gt; Yes.=C2=A0 I&#39;m not making value judgments in that statement about<=
br>
&gt; whether or not any particular individual should do such a thing,<br>
&gt; just saying that the fact that it is allowed by the standard doesn&#39=
;t<br>
&gt; mean that we can&#39;t discourage it.<br></p>
<p dir=3D"ltr">It wouldn&#39;t literally be impossible to discourage it, bu=
t it would be politically difficult if the standard were to be seen to cond=
one it. I&#39;m not aware of any case where the standard was changed to fav=
or a discouraged practice. </p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e01538e309710680528d9fb4e--

.

------=_Part_802_1914682802.1455895321125
Content-Type: multipart/alternative;
 boundary="----=_Part_803_138836308.1455895321126"

------=_Part_803_138836308.1455895321126
Content-Type: text/plain; charset=UTF-8

There has been an update to this paper available here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r1.pdf

It doesn't change anything materially (i.e doesn't buy into making
everything L-to-R) but there is a new section (7) that details some
implementation experience.

On Friday, December 4, 2015 at 11:56:15 AM UTC-5, Hyman Rosen wrote:
>
> P0145R0 is bad for two reasons.  First, it (deliberately) does not specify
> a fixed order of evaluation for all expressions (thereby failing to solve
> the problem it ostensibly addresses), and second, it does not specify that
> the order should always be strictly left-to-right (thereby failing to
> provide a rule which is simple to understand).  (Point 2 above is thus a
> consequence.)
>
> Point 1 above is wrong.  A change that specifies behavior formerly
> unspecified cannot be breaking.  Implementations that have made promises
> beyond what the standard offers can be broken, but that is not the problem
> of the committee.  Programmers who relied on their implementation's order
> are, as per Point 4 above, to be scorned.
>
> Point 4 above places the cart squarely in front of the horse.  The reason
> programmers have so much trouble with the existing rules is that the
> existing rules are stupid.  The way to fix the situation is to fix the
> stupid rules, not to treat them as a *pons asinorum* so that smug
> superiority can be asserted.  The code would not be bad if the language had
> correct rules.
>
> Point 4 prime, that programmers wish to indicate that they do not care
> about order, is, to continue the animal metaphors, a red herring.  How, for
> example, given two functions void f(); and void g();, how would you
> indicate that you want them called unsequenced?
>
> That leaves optimization.  In the old days, when parameters were passed on
> the stack, left-to-right evaluation might have led to some pessimization.
> But modern architectures pass arguments in registers, so that no longer
> matters.  Nevertheless, I do expect the proponents of the status quo to
> start pulling out examples where some compiler produces worse code, because
> that's what they always do - this argument has been going on for decades.
> The Max Planck paraphrase that "science progresses one funeral at a time"
> has never been more true.
>
> On Thu, Dec 3, 2015 at 10:52 PM, FrankHB1989 <frank...@gmail.com
> <javascript:>> wrote:
>
>> I am seriously against P0145R0
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf>.
>> As a user of C++, I urge EWG and CWG to reconsider the reasons to adopt
>> this proposal.
>>
>> To be systemic, here are my reasons:
>>
>>    1. It is a breaking change.
>>    2. It complicates the language itself. (If in doubt, compare the
>>    wording, please.)
>>    3. As mentioned above, it may harm to optimization.
>>    4. The reason represented by the proposal is unsound. It harms
>>    teachability and makes it hard to get consensus on conventional ("best")
>>    practice.
>>
>> I feels the first 2 points should be acknowledged here.
>>
>> To the 3rd point, one key point I'd note here is: *this change forbids a
>> portable way to easily express the unsequenced evaluation of an expression* *intended
>> *by the author of the code.
>>
>> For this purpose, I currently explicitly used the unsequenced function
>> parameter rule
>> <https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=master&fileviewer=file-view-default#ydef.h-938>
>> and a macro wrapper
>> <https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=master&fileviewer=file-view-default#ydef.h-956>
>> for readability. (It would probably be better with PR0146R0
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html>.)
>> However, the change by this proposal makes it a joke.
>>
>> Specifically, I can, but don't want to:
>>
>> // Not portable!
>> #pragma GCC diagnostic push
>> #pragma GCC diagnostic warning "-std=c++11" // Huh, is it documented?
>> // ...
>> #pragma GCC diagnostic pop
>>
>> For the 4th point, one key point is: *it is nonsense to support bad code*
>> .
>>
>> If the author want the clear evaluation order, do extract the
>> subexpression as a single statement (followed by ';'). This transformation
>> should not be a problem on well-formed code since even constexpr functions
>> now support multiple statements in the body, and there are lambdas.
>>
>> What if the author do not know what order they want ... who allow they to
>> code such spaghetti?
>>
>> I don't think anyone should be encourage to write such code except for
>> the purpose of testing the implementation (e.g. [-Wsequenced] or ubsan).
>> Any senior C++ user would probable agree this point easily by their
>> experience. The code should be reject by the contemporary style because it
>> causes confusion. The suggestion of change itself also has caused such
>> problem, see comments on Herb Sutter's poll
>> <http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation>
>> .
>>
>> To reduce the potential risks, a programmer who don't have enough common
>> sense about sequence rules (also imply the definition of "undefined
>> behavior"), should not be granted permission of modify the C++ code base in
>> a serious project. This is similar to C which uses similar UB rules with
>> "sequence point" wording. *These knowledge should be at very basic level
>> of the language.* The unsequenced evaluation rules are excellent
>> examples about the position and importance of these rules. Other subtle
>> rules are usually more difficult to learn. That's why I think the change
>> harms the teachability: we'd lost a chance to tell the newbies to
>> discipline themselves about being responsible to what they'd write, which
>> is hard to rescue later. This is super important for a language has so many
>> traps to use.
>>
>> There are more details about the rules, e.g. I think CWG222
>> <http://wg21.cmeerw.net/cwg/issue222>is a good change. It also loose the
>> requirements on user code, but it does not have the drawbacks above, esp.
>> it did not introduce the confusions like above.
>>
>> --
>>
>> ---
>> You received this message because you are 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:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">There has been an update to this paper available here:<div=
><br>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r1.pdf<di=
v><br></div><div>It doesn&#39;t change anything materially (i.e doesn&#39;t=
 buy into making everything L-to-R) but there is a new section (7) that det=
ails some implementation experience.<br><br>On Friday, December 4, 2015 at =
11:56:15 AM UTC-5, Hyman Rosen wrote:<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">P0145R0 is bad for two reasons.=C2=A0 First, it (de=
liberately) does not specify a fixed order of evaluation for all expression=
s (thereby failing to solve the problem it ostensibly addresses), and secon=
d, it does not specify that the order should always be strictly left-to-rig=
ht (thereby failing to provide a rule which is simple to understand). =C2=
=A0(Point 2 above is thus a consequence.)<br><br>Point 1 above is wrong.=C2=
=A0 A change that specifies behavior formerly unspecified cannot be breakin=
g.=C2=A0 Implementations that have made promises beyond what the standard o=
ffers can be broken, but that is not the problem of the committee.=C2=A0 Pr=
ogrammers who relied on their implementation&#39;s order are, as per Point =
4 above, to be scorned.<br><div><br></div><div>Point 4 above places the car=
t squarely in front of the horse.=C2=A0 The reason programmers have so much=
 trouble with the existing rules is that the existing rules are stupid.=C2=
=A0 The way to fix the situation is to fix the stupid rules, not to treat t=
hem as a <i>pons asinorum</i>=C2=A0so that smug superiority can be asserted=
..=C2=A0 The code would not be bad if the language had correct rules.<br><br=
>Point 4 prime, that programmers wish to indicate that they do not care abo=
ut order, is, to continue the animal metaphors, a red herring.=C2=A0 How, f=
or example, given two functions <font face=3D"monospace, monospace">void f(=
);</font> and <font face=3D"monospace, monospace">void g();</font>, how wou=
ld you indicate that you want them called unsequenced?<br><br>That leaves o=
ptimization.=C2=A0 In the old days, when parameters were passed on the stac=
k, left-to-right evaluation might have led to some pessimization.=C2=A0 But=
 modern architectures pass arguments in registers, so that no longer matter=
s.=C2=A0 Nevertheless, I do expect the proponents of the status quo to star=
t pulling out examples where some compiler produces worse code, because tha=
t&#39;s what they always do - this argument has been going on for decades.=
=C2=A0 The Max Planck paraphrase that &quot;science progresses one funeral =
at a time&quot; has never been more true.<br></div></div><div><br><div clas=
s=3D"gmail_quote">On Thu, Dec 3, 2015 at 10:52 PM, FrankHB1989 <span dir=3D=
"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"z4YttJCVCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">frank...@gmail.com</a>&gt;</span> wrote:<br><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">I am seriously against <a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%=
2Fp0145r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEbZmJOL_yEiq8zVZJqtZDlIWhk=
2w&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url=
?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2=
015%2Fp0145r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEbZmJOL_yEiq8zVZJqtZDl=
IWhk2w&#39;;return true;">P0145R0</a>. As a user of C++, I urge EWG and CWG=
 to reconsider the reasons to adopt this proposal.<br><br>To be systemic, h=
ere are my reasons:<br><ol><li>It is a breaking change.</li><li>It complica=
tes the language itself. (If in doubt, compare the wording, please.)</li><l=
i>As mentioned above, it may harm to optimization.</li><li>The reason repre=
sented by the proposal is unsound. It harms teachability and makes it hard =
to get consensus on conventional (&quot;best&quot;) practice.<br></li></ol>=
I feels the first 2 points should be acknowledged here.<br><br>To the 3rd p=
oint, one key point I&#39;d note here is: <b>this change forbids a portable=
 way to easily express the unsequenced evaluation of an expression</b> <i>i=
ntended </i>by the author of the code.<br><br>For this purpose, I currently=
 explicitly <a href=3D"https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a=
51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=3Dmaster&amp;fileviewe=
r=3Dfile-view-default#ydef.h-938" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fbitb=
ucket.org%2FFrankHB%2Fyslib%2Fsrc%2F82a019b2ec3a51c32a92ceb674020ae92fe2d25=
6%2FYBase%2Finclude%2Fydef.h%3Fat%3Dmaster%26fileviewer%3Dfile-view-default=
%23ydef.h-938\46sa\75D\46sntz\0751\46usg\75AFQjCNFRCb0hjjLwInQ3LUpfhH0-e_Jj=
sA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/ur=
l?q\75https%3A%2F%2Fbitbucket.org%2FFrankHB%2Fyslib%2Fsrc%2F82a019b2ec3a51c=
32a92ceb674020ae92fe2d256%2FYBase%2Finclude%2Fydef.h%3Fat%3Dmaster%26filevi=
ewer%3Dfile-view-default%23ydef.h-938\46sa\75D\46sntz\0751\46usg\75AFQjCNFR=
Cb0hjjLwInQ3LUpfhH0-e_JjsA&#39;;return true;">used the unsequenced function=
 parameter rule</a> and <a href=3D"https://bitbucket.org/FrankHB/yslib/src/=
82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=3Dmaster&a=
mp;fileviewer=3Dfile-view-default#ydef.h-956" target=3D"_blank" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%=
3A%2F%2Fbitbucket.org%2FFrankHB%2Fyslib%2Fsrc%2F82a019b2ec3a51c32a92ceb6740=
20ae92fe2d256%2FYBase%2Finclude%2Fydef.h%3Fat%3Dmaster%26fileviewer%3Dfile-=
view-default%23ydef.h-956\46sa\75D\46sntz\0751\46usg\75AFQjCNGj0tmC7XkmtIyG=
muCiPBk_1Wg6sw&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.g=
oogle.com/url?q\75https%3A%2F%2Fbitbucket.org%2FFrankHB%2Fyslib%2Fsrc%2F82a=
019b2ec3a51c32a92ceb674020ae92fe2d256%2FYBase%2Finclude%2Fydef.h%3Fat%3Dmas=
ter%26fileviewer%3Dfile-view-default%23ydef.h-956\46sa\75D\46sntz\0751\46us=
g\75AFQjCNGj0tmC7XkmtIyGmuCiPBk_1Wg6sw&#39;;return true;">a macro wrapper</=
a> for readability. (It would probably be better with <a href=3D"http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/u=
rl?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2=
F2015%2Fp0146r0.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5o=
L4IIccqCA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.=
com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpap=
ers%2F2015%2Fp0146r0.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY=
3MV5oL4IIccqCA&#39;;return true;">PR0146R0</a>.) However, the change by thi=
s proposal makes it a joke.<br><br>Specifically, I can, but don&#39;t want =
to:<br><br><div 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><div><span style=3D"color:#800"><code><div><span style=3D"color:#800">//=
 Not portable!<br>#pragma</span><span style=3D"color:#000"> GCC diagnostic =
push<br></span></div></code>#pragma</span><span style=3D"color:#000"> GCC d=
iagnostic warning </span><span style=3D"color:#080">&quot;-std=3Dc++11&quot=
;</span><span style=3D"color:#000"> </span><span style=3D"color:#800">// Hu=
h, is it documented?<br>// ...</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#800">#pragma</span><span style=3D"color:#000"> GCC di=
agnostic pop<br></span></div></code></div><br>For the 4th point, one key po=
int is: <b>it is nonsense to support bad code</b>.<br><br>If the author wan=
t the clear evaluation order, do extract the subexpression as a single stat=
ement (followed by &#39;;&#39;). This transformation should not be a proble=
m on well-formed code since even constexpr functions now support multiple s=
tatements in the body, and there are lambdas.<br><br>What if the author do =
not know what order they want ... who allow they to code such spaghetti?<br=
><br>I don&#39;t think anyone should be encourage to write such code except=
 for the purpose of testing the implementation (e.g. [-Wsequenced] or ubsan=
). Any senior C++ user would probable agree this point easily by their expe=
rience. The code should be reject by the contemporary style because it caus=
es confusion.
 The suggestion of change itself also has caused such problem, see=20
comments on <a href=3D"http://herbsutter.com/2014/12/01/a-quick-poll-about-=
order-of-evaluation" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fherbsutter.com%2F20=
14%2F12%2F01%2Fa-quick-poll-about-order-of-evaluation\46sa\75D\46sntz\0751\=
46usg\75AFQjCNF93Wsu5EyVb6nOPCTJFJOZ_bot3A&#39;;return true;" onclick=3D"th=
is.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fherbsutter.com%2F=
2014%2F12%2F01%2Fa-quick-poll-about-order-of-evaluation\46sa\75D\46sntz\075=
1\46usg\75AFQjCNF93Wsu5EyVb6nOPCTJFJOZ_bot3A&#39;;return true;">Herb Sutter=
&#39;s poll</a>.<br><br>To reduce the potential risks, a programmer who don=
&#39;t have enough common sense about sequence rules (also imply the defini=
tion of &quot;undefined behavior&quot;), should not be granted permission o=
f modify the C++ code base in a serious project. This is similar to C which=
 uses similar UB rules with &quot;sequence point&quot; wording. <b>These kn=
owledge should be at very basic level of the language.</b> The unsequenced =
evaluation rules are excellent examples about the position and importance o=
f these rules. Other subtle rules are usually more difficult to learn. That=
&#39;s why I think the change harms the teachability: we&#39;d lost a chanc=
e to tell the newbies to discipline themselves about being responsible to w=
hat they&#39;d write, which is hard to rescue later. This is super importan=
t for a language has so many traps to use.<br><br>There are more details ab=
out the rules, e.g. I think <a href=3D"http://wg21.cmeerw.net/cwg/issue222"=
 target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://=
www.google.com/url?q\75http%3A%2F%2Fwg21.cmeerw.net%2Fcwg%2Fissue222\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEFOIaLMKNmNSDLX88hzoY2veNDpg&#39;;return true;=
" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwg=
21.cmeerw.net%2Fcwg%2Fissue222\46sa\75D\46sntz\0751\46usg\75AFQjCNEFOIaLMKN=
mNSDLX88hzoY2veNDpg&#39;;return true;">CWG222 </a>is a good change. It also=
 loose the requirements on user code, but it does not have the drawbacks ab=
ove, esp. it did not introduce the confusions like above.<span><font color=
=3D"#888888"><br><br></font></span></div><span><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
z4YttJCVCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;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"z4YttJCVCQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_803_138836308.1455895321126--
------=_Part_802_1914682802.1455895321125--

.

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

The new section 7 is certainly interesting; I assume the failing test in qu=
estion was assuming a particular evaluation order that happened to be diffe=
rent from the one implemented?=20

I'm not sure the performance figures have the intended implication. To me t=
hey indicate that the Visual C++ is not currently exploiting the optimizati=
on potential of unspecified evaluation order; if it did exploit that potent=
ial fully then the change in performance would be 0% (in the case where the=
 proposed evaluation order happened to be optimal) to an 8% slowdown.=20

Note that concerns over reduction in expressiveness remain.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

------=_Part_3508_930131040.1455911460281--

.

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

The new section 7 is concluding exactly the thing I want it to conclude,
but I think it's a little... well, "disingenuous" is too strong a word,
but, it's very sketchy on what exactly their data was.

> We successfully built, installed, and booted the NT kernel.
> Then we built a large application code base, and ran =E2=80=9Cbuild, vali=
dation,
test suites.=E2=80=9D
> That uncovered sources of potential bugs due to non-portability
assumptions:
> one real-world-code test failed, out of 26.

Saying "1 of 26 tests failed" is scary to me. First of all, you only had 26
tests? Most compilers have 2600 to 26,000 tests.
Secondly, one-26th (3.8%) of those tests failed after this change? That's a
CRAZY high rate of breakage, high enough to give me pause.
Third, if only one test failed, why not quote the offending test directly
in the paper, or at least provide a link to its source? That way, readers
could judge whether the offending test is "reasonable" code or not.

In other words, I love their conclusion, but it sounds like they went out
and gathered a bunch of evidence that completely failed to support that
conclusion.
Or else, they gathered a bunch of evidence that did support their
conclusion, but then failed to present it in an understandable way.

my $.02,
=E2=80=93Arthur

On Fri, Feb 19, 2016 at 11:50 AM, Edward Catmur <ed@catmur.co.uk> wrote:

> The new section 7 is certainly interesting; I assume the failing test in
> question was assuming a particular evaluation order that happened to be
> different from the one implemented?
>
> I'm not sure the performance figures have the intended implication. To me
> they indicate that the Visual C++ is not currently exploiting the
> optimization potential of unspecified evaluation order; if it did exploit
> that potential fully then the change in performance would be 0% (in the
> case where the proposed evaluation order happened to be optimal) to an 8%
> slowdown.
>
> Note that concerns over reduction in expressiveness remain.
>
> --
>
> ---
> 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/oQUOtYX4R3o/=
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.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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/CADvuK0JocctsP3HDJ-%3D3YZ0Eoy9uxg4%3D4G%3Dr_4-Xm=
HBMXf5GeQ%40mail.gmail.com.

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

<div dir=3D"ltr">The new section 7 is concluding exactly the thing I want i=
t to conclude, but I think it&#39;s a little... well, &quot;disingenuous&qu=
ot; is too strong a word, but, it&#39;s very sketchy on what exactly their =
data was.<br><br>&gt; We successfully built, installed, and booted the NT k=
ernel.<div>&gt; Then we built a large application code base, and ran =E2=80=
=9Cbuild, validation, test suites.=E2=80=9D</div><div>&gt; That uncovered s=
ources of potential bugs due to non-portability assumptions:</div><div>&gt;=
 one real-world-code test failed, out of 26.<br><br>Saying &quot;1 of 26 te=
sts failed&quot; is scary to me. First of all, you only had 26 tests? Most =
compilers have 2600 to 26,000 tests.<br>Secondly, one-26th (3.8%) of those =
tests failed after this change? That&#39;s a CRAZY high rate of breakage, h=
igh enough to give me pause.</div><div>Third, if only one test failed, why =
not quote the offending test directly in the paper, or at least provide a l=
ink to its source? That way, readers could judge whether the offending test=
 is &quot;reasonable&quot; code or not.<br><br>In other words, I love their=
 conclusion, but it sounds like they went out and gathered a bunch of evide=
nce that completely failed to support that conclusion.<br>Or else, they gat=
hered a bunch of evidence that did support their conclusion, but then faile=
d to present it in an understandable way.<br><br>my $.02,<br>=E2=80=93Arthu=
r</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On F=
ri, Feb 19, 2016 at 11:50 AM, Edward Catmur <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">The new section 7 is certainly i=
nteresting; I assume the failing test in question was assuming a particular=
 evaluation order that happened to be different from the one implemented?<b=
r>
<br>
I&#39;m not sure the performance figures have the intended implication. To =
me they indicate that the Visual C++ is not currently exploiting the optimi=
zation potential of unspecified evaluation order; if it did exploit that po=
tential fully then the change in performance would be 0% (in the case where=
 the proposed evaluation order happened to be optimal) to an 8% slowdown.<b=
r>
<br>
Note that concerns over reduction in expressiveness remain.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/oQUOtYX4R3o/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+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--e89a8f5031e0010f4f052c26260b--

.

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

On Fri, Feb 19, 2016 at 4:27 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

>
> > We successfully built, installed, and booted the NT kernel.
> > Then we built a large application code base, and ran =E2=80=9Cbuild, va=
lidation,
> test suites.=E2=80=9D
> > That uncovered sources of potential bugs due to non-portability
> assumptions:
> > one real-world-code test failed, out of 26.
>
> Saying "1 of 26 tests failed" is scary to me.
>

They probably meant 1 of 26 *real world tests*. Of course, I am not sure
what a non-real world test case is supposed to look like. Without more
context, we may never know. Since we are not even sure if the authors watch
this forum, we are just going to keep speculating.

--=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/CALEPxftnrwGwq3MywX2bZzpx0Uu8PWV%2BiTVisHuxZnvjC=
R8Lig%40mail.gmail.com.

--001a11c38d52d47efa052c263fba
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 Fri, Feb 19, 2016 at 4:27 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<=
a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwy=
er@gmail.com</a>&gt;</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"><br>&gt; We successfully built, installed, and booted the NT ker=
nel.<div>&gt; Then we built a large application code base, and ran =E2=80=
=9Cbuild, validation, test suites.=E2=80=9D</div><div>&gt; That uncovered s=
ources of potential bugs due to non-portability assumptions:</div><div>&gt;=
 one real-world-code test failed, out of 26.<br><br>Saying &quot;1 of 26 te=
sts failed&quot; is scary to me.=C2=A0</div></div></blockquote><div><br></d=
iv><div>They probably meant 1 of 26 *real world tests*. Of course, I am not=
 sure what a non-real world test case is supposed to look like. Without mor=
e context, we may never know. Since we are not even sure if the authors wat=
ch this forum, we are just going to keep speculating.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxftnrwGwq3MywX2bZzpx0Uu8PWV%2BiT=
VisHuxZnvjCR8Lig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxftnrwGwq3=
MywX2bZzpx0Uu8PWV%2BiTVisHuxZnvjCR8Lig%40mail.gmail.com</a>.<br />

--001a11c38d52d47efa052c263fba--

.

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

We just encountered an in-house problem where turning on optimization in
the Windows compiler changed the order of evaluation of the function calls
in f(a(), b(), c()), which had silently and unknowingly been depending on a
specific order.  As I never tire of saying, having unspecified order of
evaluation is a license to create terrible latent errors that can cause a
world of trouble years and miles away from their point of origin.

On Fri, Feb 19, 2016 at 4:34 PM, Dilip Ranganathan <misc.usage@gmail.com>
wrote:

>
> On Fri, Feb 19, 2016 at 4:27 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.co=
m
> > wrote:
>
>>
>> > We successfully built, installed, and booted the NT kernel.
>> > Then we built a large application code base, and ran =E2=80=9Cbuild,
>> validation, test suites.=E2=80=9D
>> > That uncovered sources of potential bugs due to non-portability
>> assumptions:
>> > one real-world-code test failed, out of 26.
>>
>> Saying "1 of 26 tests failed" is scary to me.
>>
>
> They probably meant 1 of 26 *real world tests*. Of course, I am not sure
> what a non-real world test case is supposed to look like. Without more
> context, we may never know. Since we are not even sure if the authors wat=
ch
> this forum, we are just going to keep speculating.
>
>
> --
> You received this message because you are 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/CALEPxftnrwG=
wq3MywX2bZzpx0Uu8PWV%2BiTVisHuxZnvjCR8Lig%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxftnrw=
Gwq3MywX2bZzpx0Uu8PWV%2BiTVisHuxZnvjCR8Lig%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/CAHSYqdZdk5_pJagSZ5cxmrdq8mpu1Qs1B-8ecL0Mqc4tGUA=
4OQ%40mail.gmail.com.

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

<div dir=3D"ltr">We just encountered an in-house problem where turning on o=
ptimization in the Windows compiler changed the order of evaluation of the =
function calls in f(a(), b(), c()), which had silently and unknowingly been=
 depending on a specific order.=C2=A0 As I never tire of saying, having uns=
pecified order of evaluation is a license to create terrible latent errors =
that can cause a world of trouble years and miles away from their point of =
origin.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On F=
ri, Feb 19, 2016 at 4:34 PM, Dilip Ranganathan <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:misc.usage@gmail.com" target=3D"_blank">misc.usage@gmail.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"><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On F=
ri, Feb 19, 2016 at 4:27 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@g=
mail.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"><br>&gt; We successfully built, installed, and booted the NT kerne=
l.<div>&gt; Then we built a large application code base, and ran =E2=80=9Cb=
uild, validation, test suites.=E2=80=9D</div><div>&gt; That uncovered sourc=
es of potential bugs due to non-portability assumptions:</div><div>&gt; one=
 real-world-code test failed, out of 26.<br><br>Saying &quot;1 of 26 tests =
failed&quot; is scary to me.=C2=A0</div></div></blockquote><div><br></div><=
/span><div>They probably meant 1 of 26 *real world tests*. Of course, I am =
not sure what a non-real world test case is supposed to look like. Without =
more context, we may never know. Since we are not even sure if the authors =
watch this forum, we are just going to keep speculating.</div><div>=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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CALEPxftnrwGwq3MywX2bZzpx0Uu8PWV%2BiT=
VisHuxZnvjCR8Lig%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALEPxftnrwGwq3MywX2bZzpx0Uu8PWV%2BiTVisHuxZnvjCR8Lig%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdk5_pJagSZ5cxmrdq8mpu1Qs1B-8e=
cL0Mqc4tGUA4OQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdk5_pJagS=
Z5cxmrdq8mpu1Qs1B-8ecL0Mqc4tGUA4OQ%40mail.gmail.com</a>.<br />

--001a1143f36c67b689052c9d7acc--

.

--047d7b2e47c8f6d116052cb63de4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 26 Feb 2016 4:49 am, "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
>
> We just encountered an in-house problem where turning on optimization in
the Windows compiler changed the order of evaluation of the function calls
in f(a(), b(), c()), which had silently and unknowingly been depending on a
specific order.  As I never tire of saying, having unspecified order of
evaluation is a license to create terrible latent errors that can cause a
world of trouble years and miles away from their point of origin.
>

Can you describe the API that makes it natural to combine multiple calls to
mixed-purity functions within a single expression?

Your anecdote could apply equally to any instance of unspecified or
undefined behavior within the language or standard library; it only begins
to form part of an argument for changing the standard if you can
demonstrate that the bug could arise in good or at least unexceptional code
written today. Otherwise, it would be safest to leave evaluation order
unspecified, allowing implementations to preserve compatibility with legacy
code that assumes a different order of evaluation.

> On Fri, Feb 19, 2016 at 4:34 PM, Dilip Ranganathan <misc.usage@gmail.com>
wrote:
>>
>>
>> On Fri, Feb 19, 2016 at 4:27 PM, Arthur O'Dwyer <
arthur.j.odwyer@gmail.com> wrote:
>>>
>>>
>>> > We successfully built, installed, and booted the NT kernel.
>>> > Then we built a large application code base, and ran =E2=80=9Cbuild,
validation, test suites.=E2=80=9D
>>> > That uncovered sources of potential bugs due to non-portability
assumptions:
>>> > one real-world-code test failed, out of 26.
>>>
>>> Saying "1 of 26 tests failed" is scary to me.
>>
>>
>> They probably meant 1 of 26 *real world tests*. Of course, I am not sure
what a non-real world test case is supposed to look like. Without more
context, we may never know. Since we are not even sure if the authors watch
this forum, we are just going to keep speculating.
>>
>>
>> --
>> You received this message because you are 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/CALEPxftnrwGwq=
3MywX2bZzpx0Uu8PWV%2BiTVisHuxZnvjCR8Lig%40mail.gmail.com
..
>
>
> --
> 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/oQUOtYX4R3o/un=
subscribe
..
> 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/CAHSYqdZdk5_pJ=
agSZ5cxmrdq8mpu1Qs1B-8ecL0Mqc4tGUA4OQ%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/CAJnLdOYcptV_ZWNZNZ96zUO9B2f1WEif2k7FjF8E3%3DB2Z=
95zBw%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 26 Feb 2016 4:49 am, &quot;Hyman Rosen&quot; &lt;<a href=3D"mailto:hyman=
..rosen@gmail.com">hyman.rosen@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; We just encountered an in-house problem where turning on optimization =
in the Windows compiler changed the order of evaluation of the function cal=
ls in f(a(), b(), c()), which had silently and unknowingly been depending o=
n a specific order.=C2=A0 As I never tire of saying, having unspecified ord=
er of evaluation is a license to create terrible latent errors that can cau=
se a world of trouble years and miles away from their point of origin.<br>
&gt;</p>
<p dir=3D"ltr">Can you describe the API that makes it natural to combine mu=
ltiple calls to mixed-purity functions within a single expression?</p>
<p dir=3D"ltr">Your anecdote could apply equally to any instance of unspeci=
fied or undefined behavior within the language or standard library; it only=
 begins to form part of an argument for changing the standard if you can de=
monstrate that the bug could arise in good or at least unexceptional code w=
ritten today. Otherwise, it would be safest to leave evaluation order unspe=
cified, allowing implementations to preserve compatibility with legacy code=
 that assumes a different order of evaluation. </p>
<p dir=3D"ltr">&gt; On Fri, Feb 19, 2016 at 4:34 PM, Dilip Ranganathan &lt;=
<a href=3D"mailto:misc.usage@gmail.com">misc.usage@gmail.com</a>&gt; wrote:=
<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Feb 19, 2016 at 4:27 PM, Arthur O&#39;Dwyer &lt;<a href=3D=
"mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>&gt; wrote:=
<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; We successfully built, installed, and booted the NT kerne=
l.<br>
&gt;&gt;&gt; &gt; Then we built a large application code base, and ran =E2=
=80=9Cbuild, validation, test suites.=E2=80=9D<br>
&gt;&gt;&gt; &gt; That uncovered sources of potential bugs due to non-porta=
bility assumptions:<br>
&gt;&gt;&gt; &gt; one real-world-code test failed, out of 26.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Saying &quot;1 of 26 tests failed&quot; is scary to me.=C2=A0<=
br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; They probably meant 1 of 26 *real world tests*. Of course, I am no=
t sure what a non-real world test case is supposed to look like. Without mo=
re context, we may never know. Since we are not even sure if the authors wa=
tch this forum, we are just going to keep speculating.<br>
&gt;&gt; =C2=A0<br>
&gt;&gt;<br>
&gt;&gt; -- <br>
&gt;&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt;&gt; 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>
&gt;&gt;<br>
&gt;&gt; To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt;&gt; To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxftnrwGwq3MywX2bZzpx0Uu=
8PWV%2BiTVisHuxZnvjCR8Lig%40mail.gmail.com">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/CALEPxftnrwGwq3MywX2bZzpx0Uu8PWV%2BiTVisHuxZn=
vjCR8Lig%40mail.gmail.com</a>.<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to a topic in the=
 Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o/unsubscribe">https://gr=
oups.google.com/a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o/unsubscribe<=
/a>.<br>
&gt; 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>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdk5_pJagSZ5cxmrdq8mpu1Qs=
1B-8ecL0Mqc4tGUA4OQ%40mail.gmail.com">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAHSYqdZdk5_pJagSZ5cxmrdq8mpu1Qs1B-8ecL0Mqc4tGUA4OQ=
%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYcptV_ZWNZNZ96zUO9B2f1WEif2k7F=
jF8E3%3DB2Z95zBw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYcptV_ZW=
NZNZ96zUO9B2f1WEif2k7FjF8E3%3DB2Z95zBw%40mail.gmail.com</a>.<br />

--047d7b2e47c8f6d116052cb63de4--

.

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

On Fri, Feb 26, 2016 at 8:21 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> Can you describe the API that makes it natural to combine multiple calls
> to mixed-purity functions within a single expression?
>

Can you explain why the reaction to examples which demonstrate the need for
fixed order of evaluation is to blame the victim?

The nature of the API doesn't matter, because we are not going to be
changing any of our existing code to match some ideal of purity that would
allow unspecified order of evaluation to be a positive feature.
Unspecified order of evaluation leaves latent errors in code that are
easily overlooked by inspection and undetectable by testing, until the day,
perhaps years after the code was written, they explode.  Just like this.

--
You received this message because you are 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/CAHSYqdaXOcZFkXTW1hsvfoQ04%3Dr-z3gOJ7Bkk9PybTw%3D28t2wA%40mail.gmail.com.

--001a11440176fbfea2052cedfc9b
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, Feb 26, 2016 at 8:21 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</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">Can you de=
scribe the API that makes it natural to combine multiple calls to mixed-pur=
ity functions within a single expression?</p></span></blockquote><div><br>C=
an you explain why the reaction to examples which demonstrate the need for =
fixed order of evaluation is to blame the victim?<br><br>The nature of the =
API doesn&#39;t matter, because we are not going to be changing any of our =
existing code to match some ideal of purity that would allow unspecified or=
der of evaluation to be a positive feature.=C2=A0 Unspecified order of eval=
uation leaves latent errors in code that are easily overlooked by inspectio=
n and undetectable by testing, until the day, perhaps years after the code =
was written, they explode.=C2=A0 Just like this.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaXOcZFkXTW1hsvfoQ04%3Dr-z3gOJ7=
Bkk9PybTw%3D28t2wA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaXOcZF=
kXTW1hsvfoQ04%3Dr-z3gOJ7Bkk9PybTw%3D28t2wA%40mail.gmail.com</a>.<br />

--001a11440176fbfea2052cedfc9b--

.

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

On 29 February 2016 at 14:52, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Fri, Feb 26, 2016 at 8:21 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> Can you describe the API that makes it natural to combine multiple calls
>> to mixed-purity functions within a single expression?
>>
>
> Can you explain why the reaction to examples which demonstrate the need
> for fixed order of evaluation is to blame the victim?
>

Maybe it is the same reason that some people react to examples which
demonstrate the evaluation order problem by insisting that the fix is to
define the order of evaluation, no matter the cost?

Constantly repeating the solution you want while ignoring all other
concerns is not a way to build consensus, IMHO.
--
 Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com <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%2BP%2BKQHaEafkT0Xpys6YPCGap-7MSgcriCu9dw%3DhckPgEA%40mail.gmail.com.

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

<div dir=3D"ltr">On 29 February 2016 at 14:52, Hyman Rosen <span dir=3D"ltr=
">&lt;<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rose=
n@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><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, Feb 26=
, 2016 at 8:21 PM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Pr=
oposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" t=
arget=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span><p dir=3D"ltr">Can you describe the API that m=
akes it natural to combine multiple calls to mixed-purity functions within =
a single expression?</p></span></blockquote></span><div><br>Can you explain=
 why the reaction to examples which demonstrate the need for fixed order of=
 evaluation is to blame the victim?<br></div></div></div></div></blockquote=
><div><br></div><div>Maybe it is the same reason that some people react to =
examples which demonstrate the evaluation order problem by insisting that t=
he fix is to define the order of evaluation, no matter the cost?</div><div>=
<br></div><div>Constantly repeating the solution you want while ignoring al=
l other concerns is not a way to build consensus, IMHO.<br>-- <br><div clas=
s=3D"gmail_signature"><div dir=3D"ltr">=C2=A0Nevin &quot;:-)&quot; Liber=C2=
=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@cplusplusguy.com</a>&gt;=C2=A0 +1-847-691-1404<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP%2BKQHaEafkT0Xpys6YPCGap-7M=
SgcriCu9dw%3DhckPgEA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP%=
2BKQHaEafkT0Xpys6YPCGap-7MSgcriCu9dw%3DhckPgEA%40mail.gmail.com</a>.<br />

--001a11c3c9088f5c39052cee0eb9--

.

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

On Mon, Feb 29, 2016 at 2:56 PM, Nevin Liber <nevin@cplusplusguy.com> wrote:
>
> Constantly repeating the solution you want while ignoring all other
> concerns is not a way to build consensus, IMHO.
>

Sometimes the only way to build consensus is to wear down the other side.
Having a real-world example is a way to do 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/CAHSYqdapuk%3DArV8xj-YBCQ2M9TFETrGzeihoC3AUaYQmpkToZw%40mail.gmail.com.

--001a1141c87ed0929f052cee3be4
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, Feb 29, 2016 at 2:56 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:nevin@cplusplusguy.com" target=3D"_blank">nevin@cplusplusguy.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>Constantly repeating the s=
olution you want while ignoring all other concerns is not a way to build co=
nsensus, IMHO.</div></div></div></div></blockquote><div><br>Sometimes the o=
nly way to build consensus is to wear down the other side.=C2=A0 Having a r=
eal-world example is a way to do that.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdapuk%3DArV8xj-YBCQ2M9TFETrGzei=
hoC3AUaYQmpkToZw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdapuk%3DA=
rV8xj-YBCQ2M9TFETrGzeihoC3AUaYQmpkToZw%40mail.gmail.com</a>.<br />

--001a1141c87ed0929f052cee3be4--

.

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

On 1 Mar 2016 04:10, "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
>
> On Mon, Feb 29, 2016 at 2:56 PM, Nevin Liber <nevin@cplusplusguy.com>
wrote:
>>
>> Constantly repeating the solution you want while ignoring all other
concerns is not a way to build consensus, IMHO.
>
>
> Sometimes the only way to build consensus is to wear down the other
side.  Having a real-world example is a way to do that.
>

An anecdote does not constitute a real-world example.

I invited you to expand on your anecdote (I'm assuming you can't share full
details) and you chose to interpret that as blaming the victim. Your
arguments carry less weight if you cannot demonstrate that you have at
least considered other options: deprecating older APIs in favor of
command-query separation, requesting warning diagnostics for code depending
on evaluation order, or requesting vendor compatibility modes (-fltr and
-frtl, say, along the lines of -fwrapv, or equivalent pragmas for
finer-grained control).

If you can't or won't change any of your code, I can't see why -fltr
shouldn't be a satisfactory option - and if it really is the superior
choice, then in a few years everyone will be using it and mandating it can
be considered.

--
You received this message because you are 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/CAJnLdObS%3DMdf9Rqat2gWNeHnyWp4v7_8hRtsCkGyK%3D4JN_8QBQ%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 1 Mar 2016 04:10, &quot;Hyman Rosen&quot; &lt;<a href=3D"mailto:hyman.ro=
sen@gmail.com">hyman.rosen@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Mon, Feb 29, 2016 at 2:56 PM, Nevin Liber &lt;<a href=3D"mailto:nev=
in@cplusplusguy.com">nevin@cplusplusguy.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Constantly repeating the solution you want while ignoring all othe=
r concerns is not a way to build consensus, IMHO.<br>
&gt;<br>
&gt;<br>
&gt; Sometimes the only way to build consensus is to wear down the other si=
de.=C2=A0 Having a real-world example is a way to do that.<br>
&gt;</p>
<p dir=3D"ltr">An anecdote does not constitute a real-world example. </p>
<p dir=3D"ltr">I invited you to expand on your anecdote (I&#39;m assuming y=
ou can&#39;t share full details) and you chose to interpret that as blaming=
 the victim. Your arguments carry less weight if you cannot demonstrate tha=
t you have at least considered other options: deprecating older APIs in fav=
or of command-query separation, requesting warning diagnostics for code dep=
ending on evaluation order, or requesting vendor compatibility modes (-fltr=
 and -frtl, say, along the lines of -fwrapv, or equivalent pragmas for fine=
r-grained control).</p>
<p dir=3D"ltr">If you can&#39;t or won&#39;t change any of your code, I can=
&#39;t see why -fltr shouldn&#39;t be a satisfactory option - and if it rea=
lly is the superior choice, then in a few years everyone will be using it a=
nd mandating it can be considered. </p>

<p></p>

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

--001a1140f7502f5c55052d1be1cf--

.

This is a multi-part message in MIME format.
--------------000104000509090409020207
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 03.03.2016 um 03:37 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>
> On 1 Mar 2016 04:10, "Hyman Rosen" <hyman.rosen@gmail.com
> <mailto:hyman.rosen@gmail.com>> wrote:
> >
> > On Mon, Feb 29, 2016 at 2:56 PM, Nevin Liber <nevin@cplusplusguy.com
> <mailto:nevin@cplusplusguy.com>> wrote:
> >>
> >> Constantly repeating the solution you want while ignoring all other
> concerns is not a way to build consensus, IMHO.
> >
> >
> > Sometimes the only way to build consensus is to wear down the other
> side.  Having a real-world example is a way to do that.
> >
>
> An anecdote does not constitute a real-world example.
>
> I invited you to expand on your anecdote (I'm assuming you can't share
> full details) and you chose to interpret that as blaming the victim.
> Your arguments carry less weight if you cannot demonstrate that you
> have at least considered other options: deprecating older APIs in
> favor of command-query separation, requesting warning diagnostics for
> code depending on evaluation order, or requesting vendor compatibility
> modes (-fltr and -frtl, say, along the lines of -fwrapv, or equivalent
> pragmas for finer-grained control).
>
> If you can't or won't change any of your code, I can't see why -fltr
> shouldn't be a satisfactory option - and if it really is the superior
> choice, then in a few years everyone will be using it and mandating it
> can be considered.
>
Can you really blame someone for writing "f(a(), b(), c())" ? That is
the most natural thing to do in any programming language out there. From
my experience it is the first thing people do intuitively when learning
programming. They expect things to be evaluated from left to right,
because that is the order they typed it in. And it always works. Except
when it doesn't (but only in C/C++), and then they spend hours or days
bug hunting (good way to ruin the programming experience for freshmen).
And then try explaining to them why sometimes it's OK, but sometimes it
isn't (at a point at which they would unlikely understand the point of
command-query separation) and why they can't do it the natural way but
have to go ot of their way to work around this "stupid language" that
they never want to touch again. Frustrations like this are why so few
students come out of university and think C++ is great, why it is
increasingly harder to find C++ developers. Of course one can't blame
*only* the language. Some professors and curriculums simply suck but if
the students do programming exercises on their own and run into issues
like this it ruins the experience. And then I hear Bjarne saying C++ is
novice friendly and I cry a little on the inside.

This evaluation issue is something that everyone gets bitten by at some
point. But it's never a big gaping wound that stands out to every
reviewer. It's more like a venom bite, slowly working its way and
suddenly your heart stops beating.

--
You received this message because you are 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/56D84F8E.8010503%40gmail.com.

--------------000104000509090409020207
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 03.03.2016 um 03:37 schrieb 'Edward Catmur' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CAJnLdObS=3DMdf9Rqat2gWNeHnyWp4v7_8hRtsCkGyK=3D4JN_8QBQ@mail.gm=
ail.com"
      type=3D"cite">
      <p dir=3D"ltr"><br>
        On 1 Mar 2016 04:10, "Hyman Rosen" &lt;<a moz-do-not-send=3D"true"
          href=3D"mailto:hyman.rosen@gmail.com">hyman.rosen@gmail.com</a>&g=
t;
        wrote:<br>
        &gt;<br>
        &gt; On Mon, Feb 29, 2016 at 2:56 PM, Nevin Liber &lt;<a
          moz-do-not-send=3D"true" href=3D"mailto:nevin@cplusplusguy.com"><=
a class=3D"moz-txt-link-abbreviated" href=3D"mailto:nevin@cplusplusguy.com"=
>nevin@cplusplusguy.com</a></a>&gt;
        wrote:<br>
        &gt;&gt;<br>
        &gt;&gt; Constantly repeating the solution you want while
        ignoring all other concerns is not a way to build consensus,
        IMHO.<br>
        &gt;<br>
        &gt;<br>
        &gt; Sometimes the only way to build consensus is to wear down
        the other side.=C2=A0 Having a real-world example is a way to do
        that.<br>
        &gt;</p>
      <p dir=3D"ltr">An anecdote does not constitute a real-world example.
      </p>
      <p dir=3D"ltr">I invited you to expand on your anecdote (I'm
        assuming you can't share full details) and you chose to
        interpret that as blaming the victim. Your arguments carry less
        weight if you cannot demonstrate that you have at least
        considered other options: deprecating older APIs in favor of
        command-query separation, requesting warning diagnostics for
        code depending on evaluation order, or requesting vendor
        compatibility modes (-fltr and -frtl, say, along the lines of
        -fwrapv, or equivalent pragmas for finer-grained control).</p>
      <p dir=3D"ltr">If you can't or won't change any of your code, I
        can't see why -fltr shouldn't be a satisfactory option - and if
        it really is the superior choice, then in a few years everyone
        will be using it and mandating it can be considered. </p>
    </blockquote>
    Can you really blame someone for writing "f(a(), b(), c())" ? That
    is the most natural thing to do in any programming language out
    there. From my experience it is the first thing people do
    intuitively when learning programming. They expect things to be
    evaluated from left to right, because that is the order they typed
    it in. And it always works. Except when it doesn't (but only in
    C/C++), and then they spend hours or days bug hunting (good way to
    ruin the programming experience for freshmen). And then try
    explaining to them why sometimes it's OK, but sometimes it isn't (at
    a point at which they would unlikely understand the point of
    command-query separation) and why they can't do it the natural way
    but have to go ot of their way to work around this "stupid language"
    that they never want to touch again. Frustrations like this are why
    so few students come out of university and think C++ is great, why
    it is increasingly harder to find C++ developers. Of course one
    can't blame *only* the language. Some professors and curriculums
    simply suck but if the students do programming exercises on their
    own and run into issues like this it ruins the experience. And then
    I hear Bjarne saying C++ is novice friendly and I cry a little on
    the inside.<br>
    <br>
    This evaluation issue is something that everyone gets bitten by at
    some point. But it's never a big gaping wound that stands out to
    every reviewer. It's more like a venom bite, slowly working its way
    and suddenly your heart stops beating.<br>
  </body>
</html>

<p></p>

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

--------------000104000509090409020207--

.

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

On Wed, Mar 2, 2016 at 9:37 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> An anecdote does not constitute a real-world example.
>
It's a real-world example.  We had such code. It broke when we turned on
the WholeProgramOptimization option.  It happened this January.  I don't
have the details of the function calls because the report didn't include
them, just the pattern.

> I invited you to expand on your anecdote (I'm assuming you can't share
> full details) and you chose to interpret that as blaming the victim.
>
There's nothing to expand upon.  It's as simple as I have always
maintained.  Unspecified behavior allows latent errors to linger in code
for years, becoming exposed only when something in the compilation
environment changes.

Your arguments carry less weight if you cannot demonstrate that you have at
> least considered other options:
>
Options for what?

> deprecating older APIs in favor of command-query separation,
>
We have a lot of old APIs, involving millions of lines of code.  We're not
going to be changing them.

> requesting warning diagnostics for code depending on evaluation order
>
This is impossible to use, because it would generate warnings on every
expression involving more than one unsequenced function call.

> or requesting vendor compatibility modes (-fltr and -frtl, say, along the
> lines of -fwrapv, or equivalent pragmas for finer-grained control).
>
I don't believe such modes have been notably successful.  The
floating-point accuracy ones, for example, are horrible. And see below,

> If you can't or won't change any of your code, I can't see why -fltr
> shouldn't be a satisfactory option - and if it really is the superior
> choice, then in a few years everyone will be using it and mandating it can
> be considered.
>
It's not satisfactory because our code runs on several different platforms,
using several different compilers.  We would need all of them to support
this option, and since we support legacy platforms (e.g., AIX and SunOS),
that is difficult.  If it were part of the standard, it would be more
likely to show up everywhere.  And how could you possibly measure "better"
in this context?  It's a change which will be almost entirely
undetectable.  It's effect will be to prevent people from writing code that
accidentally works but actually has unspecified behavior.  It's like asking
to measure the effects of having a guardian angel - how do you measure the
number of accidents that never happen?

But regardless, the point is that having unspecified order of evaluation is
bad for the C++ language and bad for C++ programmers.  I'm not just
searching for a way to immunize my code from this poor decision, I want
this poor decision removed from the language so that no one needs to suffer
from 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/CAHSYqdZF1MP7KYw2nzXW182oHZ-37uWX2gEpbj9gVEbw85%3D9ww%40mail.gmail.com.

--001a1143f15466486d052d28e851
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, Mar 2, 2016 at 9:37 PM, &#39;Edward Catmur&#39; via ISO C++ Standard - =
Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isoc=
pp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</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 class=3D"HOEnZb"><div class=3D"h5"><p =
dir=3D"ltr"><span style=3D"color:rgb(34,34,34)">An anecdote does not consti=
tute a real-world example.</span></p></div></div></blockquote><div>It&#39;s=
 a real-world example.=C2=A0 We had such code. It broke when we turned on t=
he WholeProgramOptimization option.=C2=A0 It happened this January.=C2=A0 I=
 don&#39;t have the details of the function calls because the report didn&#=
39;t include them, just the pattern.</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">I invited you to expand on your anecdote (I&#39;m assuming y=
ou can&#39;t share full details) and you chose to interpret that as blaming=
 the victim.</p></blockquote><div>There&#39;s nothing to expand upon.=C2=A0=
 It&#39;s as simple as I have always maintained.=C2=A0 Unspecified behavior=
 allows latent errors to linger in code for years, becoming exposed only wh=
en something in the compilation environment changes.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><p dir=3D"ltr"> Your arguments carry less weight if y=
ou cannot demonstrate that you have at least considered other options:</p><=
/blockquote><div>Options for what?=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><p dir=3D"ltr">deprecating older APIs in favor of command-query separatio=
n,</p></blockquote><div>We have a lot of old APIs, involving millions of li=
nes of code.=C2=A0 We&#39;re not going to be changing them.</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"> requesting warning diagnostics for cod=
e depending on evaluation order</p></blockquote><div>This is impossible to =
use, because it would generate warnings on every expression involving more =
than one unsequenced function call.</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"> or requesting vendor compatibility modes (-fltr and -frtl, say=
, along the lines of -fwrapv, or equivalent pragmas for finer-grained contr=
ol).</p></blockquote><div>I don&#39;t believe such modes have been notably =
successful.=C2=A0 The floating-point accuracy ones, for example, are horrib=
le. And see below,</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">If you can&#39;t or won&#39;t change any of your code, I can=
&#39;t see why -fltr shouldn&#39;t be a satisfactory option - and if it rea=
lly is the superior choice, then in a few years everyone will be using it a=
nd mandating it can be considered.</p></blockquote><div>It&#39;s not satisf=
actory because our code runs on several different platforms, using several =
different compilers.=C2=A0 We would need all of them to support this option=
, and since we support legacy platforms (e.g., AIX and SunOS), that is diff=
icult.=C2=A0 If it were part of the standard, it would be more likely to sh=
ow up everywhere.=C2=A0 And how could you possibly measure &quot;better&quo=
t; in this context?=C2=A0 It&#39;s a change which will be almost entirely u=
ndetectable.=C2=A0 It&#39;s effect will be to prevent people from writing c=
ode that accidentally works but actually has unspecified behavior.=C2=A0 It=
&#39;s like asking to measure the effects of having a guardian angel - how =
do you measure the number of accidents that never happen?<br><br>But regard=
less, the point is that having unspecified order of evaluation is bad for t=
he C++ language and bad for C++ programmers.=C2=A0 I&#39;m not just searchi=
ng for a way to immunize my code from this poor decision, I want this poor =
decision removed from the language so that no one needs to suffer from it.<=
/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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZF1MP7KYw2nzXW182oHZ-37uWX2gEp=
bj9gVEbw85%3D9ww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZF1MP7KY=
w2nzXW182oHZ-37uWX2gEpbj9gVEbw85%3D9ww%40mail.gmail.com</a>.<br />

--001a1143f15466486d052d28e851--

.

> But regardless, the point is that having unspecified order of evaluation =
is bad for the C++ language and bad for C++ programmers.  I'm not just sear=
ching for a way to immunize my code from this poor decision, I want this po=
or decision removed from the language so that no one needs to suffer from i=
t.

I have always had the suspicion that the undefined evaluation order is in t=
he language only because Kernighan and Ritchie simply forgot to nail it dow=
n way back when. But I can=E2=80=99t find any written evidence for this, so=
 this may be wrong. Does anyone know for sure?

Cheers,

Michi.

--=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/D76FE529-8660-4034-95B3-75DC89F9796A%40canonical=
..com.

.

--089e0115fd32b7769c052d2d02f1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 3, 2016 at 4:49 PM, Michi Henning <michi.henning@canonical.com>
wrote:

> > But regardless, the point is that having unspecified order of evaluatio=
n
> is bad for the C++ language and bad for C++ programmers.  I'm not just
> searching for a way to immunize my code from this poor decision, I want
> this poor decision removed from the language so that no one needs to suff=
er
> from it.
>
> I have always had the suspicion that the undefined evaluation order is in
> the language only because Kernighan and Ritchie simply forgot to nail it
> down way back when. But I can=E2=80=99t find any written evidence for thi=
s, so this
> may be wrong. Does anyone know for sure?
>
> They didn't forget. They seem to have deliberately left it unspecified.

Source: https://www.eskimo.com/~scs/cclass/notes/sx7c.html

quote: The moral is that writing code that depends on order of evaluation
is a bad programming practice in any language. Naturally, it is necessary
to know what things to avoid, but if you don't know *how* they are done on
various machines, you won't be tempted to take advantage of a particular
implementation.

My faith in humanity is lost forever.

--=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/CALEPxfvJG2oqTu2zQbE_iiTDb0giNsExfH3tR_TYRJqpY2n=
Erw%40mail.gmail.com.

--089e0115fd32b7769c052d2d02f1
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 Thu, Mar 3, 2016 at 4:49 PM, Michi Henning <span dir=3D"ltr">&lt;<a href=
=3D"mailto:michi.henning@canonical.com" target=3D"_blank">michi.henning@can=
onical.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(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">&gt; =
But regardless, the point is that having unspecified order of evaluation is=
 bad for the C++ language and bad for C++ programmers.=C2=A0 I&#39;m not ju=
st searching for a way to immunize my code from this poor decision, I want =
this poor decision removed from the language so that no one needs to suffer=
 from it.<br>
<br>
</span>I have always had the suspicion that the undefined evaluation order =
is in the language only because Kernighan and Ritchie simply forgot to nail=
 it down way back when. But I can=E2=80=99t find any written evidence for t=
his, so this may be wrong. Does anyone know for sure?<br>
<br></blockquote><div>They didn&#39;t forget. They seem to have deliberatel=
y left it unspecified.</div><div><br></div><div>Source: <a href=3D"https://=
www.eskimo.com/~scs/cclass/notes/sx7c.html">https://www.eskimo.com/~scs/ccl=
ass/notes/sx7c.html</a></div><div><br></div><div>quote:=C2=A0<font color=3D=
"#ff0000"><span style=3D"font-family:&#39;Times New Roman&#39;;font-size:me=
dium">The moral is that writing code that depends on order of evaluation is=
 a bad programming practice in any language. Naturally, it is necessary to =
know what things to avoid, but if you don&#39;t know=C2=A0</span><i style=
=3D"font-family:&#39;Times New Roman&#39;;font-size:medium">how</i><span st=
yle=3D"font-family:&#39;Times New Roman&#39;;font-size:medium">=C2=A0they a=
re done on various machines, you won&#39;t be tempted to take advantage of =
a particular implementation.</span>=C2=A0</font></div><div><br></div><div>M=
y faith in humanity is lost forever.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxfvJG2oqTu2zQbE_iiTDb0giNsExfH3t=
R_TYRJqpY2nErw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfvJG2oqTu2z=
QbE_iiTDb0giNsExfH3tR_TYRJqpY2nErw%40mail.gmail.com</a>.<br />

--089e0115fd32b7769c052d2d02f1--

.

--Apple-Mail=_0E34EFA7-B32B-4EAC-A30F-286ECE04627A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> They didn't forget. They seem to have deliberately left it unspecified.
>=20
> Source: https://www.eskimo.com/~scs/cclass/notes/sx7c.html <https://www.e=
skimo.com/~scs/cclass/notes/sx7c.html>
>=20
> quote: The moral is that writing code that depends on order of evaluation=
 is a bad programming practice in any language. Naturally, it is necessary =
to know what things to avoid, but if you don't know how they are done on va=
rious machines, you won't be tempted to take advantage of a particular impl=
ementation.=20

I just dug out my 1st edition copy of K&R and, yes, those words are indeed =
there (final para on page 50).

To state that =E2=80=9Cwriting code that depends on order of evaluation is =
bad programming practice in any language=E2=80=9D is to make a rather sweep=
ing statement, and one that is contradicted by many modern languages. In K&=
R=E2=80=99s defense, the statement was made almost 40 years ago.

We use sequencing all the time. If I write

a =3D b;
c +=3D 2 * a;

I=E2=80=99d be rather surprised if the compiler were to re-order these two =
statements. But, for some reason I can=E2=80=99t quite follow, doing the sa=
me thing for expressions is considered bad, even though a complex expressio=
n is just a sequence of simple statements. Why anyone would deem it desirab=
le for things to be evaluated in any order is beyond me, hypothetical compi=
le-time optimizations notwithstanding.

The second rationale strikes me as completely back to front:

=E2=80=9CIf you don=E2=80=99t know how they are done on various machines, y=
ou won=E2=80=99t be tempted to take advantage of a particular implementatio=
n.=E2=80=9D

The problem isn=E2=80=99t that people are tempted to take advantage. The pr=
oblem is that they write something, test it, find that it works, and move o=
n. All the while being blissfully ignorant that the working code, as a matt=
er of fact, has undefined behavior.

But, hey, this is C++, right? If we can make it more complicated, let=E2=80=
=99s!

> My faith in humanity is lost forever.

I=E2=80=99m not quite as bleak as that, but close. After twenty-five years =
of writing C++ on a daily basis, I am still spending a large part of my pro=
gramming effort watching myself over my own shoulder, just to avoid shootin=
g myself in the foot with something silly, such as forgetting to disable a =
copy constructor or accidentally relying on undefined evaluation order. It=
=E2=80=99s tedious, to say the least.

And, after twenty-five years, I=E2=80=99m still unable to say that C++ is e=
asy. It isn=E2=80=99t, period. If performance doesn=E2=80=99t matter, give =
me Java or C# any day. (And, no, I=E2=80=99m not a Java weenie. But Java *i=
s* easy, certainly when compared to C++.)

Michi.

PS: So, there, I=E2=80=99ve spoken the J-word. Now go and shoot me :-)

--=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/17BED39D-CD86-42DA-8FD9-0448CA3C3407%40canonical=
..com.

--Apple-Mail=_0E34EFA7-B32B-4EAC-A30F-286ECE04627A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">They didn't =
forget. They seem to have deliberately left it unspecified.</div><div class=
=3D""><br class=3D""></div><div class=3D"">Source: <a href=3D"https://www.e=
skimo.com/~scs/cclass/notes/sx7c.html" class=3D"">https://www.eskimo.com/~s=
cs/cclass/notes/sx7c.html</a></div><div class=3D""><br class=3D""></div><di=
v class=3D"">quote:&nbsp;<font color=3D"#ff0000" class=3D""><span style=3D"=
font-family: 'Times New Roman'; font-size: inherit;" class=3D"">The moral i=
s that writing code that depends on order of evaluation is a bad programmin=
g practice in any language. Naturally, it is necessary to know what things =
to avoid, but if you don't know&nbsp;</span><i style=3D"font-family: 'Times=
 New Roman'; font-size: inherit;" class=3D"">how</i><span style=3D"font-fam=
ily: 'Times New Roman'; font-size: inherit;" class=3D"">&nbsp;they are done=
 on various machines, you won't be tempted to take advantage of a particula=
r implementation.</span>&nbsp;</font></div></div></div></div></div></blockq=
uote><div><br class=3D""></div>I just dug out my 1st edition copy of K&amp;=
R and, yes, those words are indeed there (final para on page 50).</div><div=
><br class=3D""></div><div>To state that =E2=80=9Cwriting code that depends=
 on order of evaluation is bad programming practice in any language=E2=80=
=9D is to make a rather sweeping statement, and one that is contradicted by=
 many modern languages. In K&amp;R=E2=80=99s defense, the statement was mad=
e almost 40 years ago.</div><div><br class=3D""></div><div>We use sequencin=
g all the time. If I write</div><div><br class=3D""></div><div>a =3D b;</di=
v><div>c +=3D 2 * a;</div><div><br class=3D""></div><div>I=E2=80=99d be rat=
her surprised if the compiler were to re-order these two statements. But, f=
or some reason I can=E2=80=99t quite follow, doing the same thing for expre=
ssions is considered bad, even though a complex expression is just a sequen=
ce of simple statements. Why anyone would deem it desirable for things to b=
e evaluated in any order is beyond me, hypothetical compile-time optimizati=
ons notwithstanding.</div><div><br class=3D""></div><div>The second rationa=
le strikes me as completely back to front:</div><div><br class=3D""></div><=
div>=E2=80=9CIf you don=E2=80=99t know how they are done on various machine=
s, you won=E2=80=99t be tempted to take advantage of a particular implement=
ation.=E2=80=9D</div><div><br class=3D""></div><div>The problem isn=E2=80=
=99t that people are tempted to take advantage. The problem is that they wr=
ite something, test it, find that it works, and move on. All the while bein=
g blissfully ignorant that the working code, as a matter of fact, has undef=
ined behavior.</div><div><br class=3D""></div><div>But, hey, this is C++, r=
ight? If we can make it more complicated, let=E2=80=99s!</div><div><br clas=
s=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr=
" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div cla=
ss=3D"">My faith in humanity is lost forever.</div></div></div></div></div>=
</blockquote><div><br class=3D""></div>I=E2=80=99m not quite as bleak as th=
at, but close. After twenty-five years of writing C++ on a daily basis, I a=
m still spending a large part of my programming effort watching myself over=
 my own shoulder, just to avoid shooting myself in the foot with something =
silly, such as forgetting to disable a copy constructor or accidentally rel=
ying on undefined evaluation order. It=E2=80=99s tedious, to say the least.=
</div><div><br class=3D""></div><div>And, after twenty-five years, I=E2=80=
=99m still unable to say that C++ is easy. It isn=E2=80=99t, period. If per=
formance doesn=E2=80=99t matter, give me Java or C# any day. (And, no, I=E2=
=80=99m not a Java weenie. But Java *is* easy, certainly when compared to C=
++.)</div><div><br class=3D""></div><div>Michi.</div><div><br class=3D""></=
div><div>PS: So, there, I=E2=80=99ve spoken the J-word. Now go and shoot me=
 :-)</div><div><br class=3D""></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/17BED39D-CD86-42DA-8FD9-0448CA3C3407%=
40canonical.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/17BED39D-CD86-42DA-8FD9-0448CA3C3=
407%40canonical.com</a>.<br />

--Apple-Mail=_0E34EFA7-B32B-4EAC-A30F-286ECE04627A--

.

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

No shooting for using the =C2=ABJ=C2=BB word, at least not from me.

@Miro : =C2=ABThey expect things to be evaluated from left to right, becaus=
e
that is the order they typed it in. And it always works. Except when it
doesn't (but only in C/C++)=C2=BB. If my memory is correct, Lisp / Scheme
evaluated functions right-to-left. It was/is a specified order, though. C#
mandates left-to-right. C++ and C state the relative ordering of f() and
g() in this expression is not something you should count on. I think the
position on relative ordering of a priori independent statements such as
f() ad g() in something like =C2=ABfct(f(), g())=C2=BB is more one of aesth=
etics than
something sound; I was never taught, way back when that it would be a
sensible thing to expect f() and g() to be ordered in a specific way, and I
definitely don't think, even today, that writing code that depends on such
an ordering makes sense in general. If it works due to this dependency,
it's not an easy thing to maintain in the long run.

@Hyman : see above. I am sad that code gets broken due to expectancies on
the ordering of such statements, but I'm saddened that such code was
written in the first place. There might be good reasons to specifiy the
ordering of such statements in the standard, but fixing a priori broken
code is not it, at least not in my mind. Should we impose an ordering,
which we could, this use case would not (to me) be one of the reasons to
support the changed (it is reminescent, in a way, of some of the debates
regarding whether automating move semantics would ba a good thing since it
would break classes with hidden invariants). I'm not against your position
that specifying ordering could be a good thing, but I'd look for another
example than this. If you have something where it would be useful for
something else than code that was incorrect in the first place, I think it
would be useful, and I would like to know more about it.

@Michi : I don't think the fact that there is no a priori ordering of such
statements makes the language more complicated. Knowing they are unordered
(could be done in parallel should they be [[pure]] or whatever) or knowing
they are mandated to be evaluated in a specific order (right-to-left,
left-to-right) seems of equivalent complexity to me. Even if the ordering
was mandated, I'd avoid depending on it (if my company uses more than one
programming language, porting an algorithm to other languages would be made
unnecessarily complex due to this dependence; it's a very bad idea).

@Michi : the dependency you are bringing forward is of another nature,
being a data dependency where the first line influences the second one in
an ordered sequence of instructions. I don't think anyone on this thread
questions the idea of sequence per se, no matter what individual positions
are.

In a more general sense:


   - things such as obj.f().g() do (to me) make sense only as
   ((obj).f()).g(), so let's not do anything to break this
   - things such as obj.f(obj).g(obj.f()) make sense to me as respecting
   =C2=ABparenthesis ordering=C2=BB as on the prior bullet
   - if f() and g() have side-effects, then such expressions are just
   trouble. There's no ordering that would solve the deeper problems in a
   satisfactory manner (AFAIK)
   - we already have many weird cases such as =C2=ABcout << f() << g();=C2=
=BB not
   necessarily being equivalent as =C2=ABcout << f(); cout << g();=C2=BB in=
 the presence
   of side-effects in f() and g(). The key problem is not the relative
   ordering of the functions, at least it does not seem so to me
   - if we are imposing an ordering to fix such things, I think we're
   making a mistake


Cheers!

2016-03-03 20:06 GMT-05:00 Michi Henning <michi.henning@canonical.com>:

> They didn't forget. They seem to have deliberately left it unspecified.
>
> Source: https://www.eskimo.com/~scs/cclass/notes/sx7c.html
>
> quote: The moral is that writing code that depends on order of evaluation
> is a bad programming practice in any language. Naturally, it is necessary
> to know what things to avoid, but if you don't know *how* they are done
> on various machines, you won't be tempted to take advantage of a particul=
ar
> implementation.
>
>
> I just dug out my 1st edition copy of K&R and, yes, those words are indee=
d
> there (final para on page 50).
>
> To state that =E2=80=9Cwriting code that depends on order of evaluation i=
s bad
> programming practice in any language=E2=80=9D is to make a rather sweepin=
g
> statement, and one that is contradicted by many modern languages. In K&R=
=E2=80=99s
> defense, the statement was made almost 40 years ago.
>
> We use sequencing all the time. If I write
>
> a =3D b;
> c +=3D 2 * a;
>
> I=E2=80=99d be rather surprised if the compiler were to re-order these tw=
o
> statements. But, for some reason I can=E2=80=99t quite follow, doing the =
same thing
> for expressions is considered bad, even though a complex expression is ju=
st
> a sequence of simple statements. Why anyone would deem it desirable for
> things to be evaluated in any order is beyond me, hypothetical compile-ti=
me
> optimizations notwithstanding.
>
> The second rationale strikes me as completely back to front:
>
> =E2=80=9CIf you don=E2=80=99t know how they are done on various machines,=
 you won=E2=80=99t be
> tempted to take advantage of a particular implementation.=E2=80=9D
>
> The problem isn=E2=80=99t that people are tempted to take advantage. The =
problem
> is that they write something, test it, find that it works, and move on. A=
ll
> the while being blissfully ignorant that the working code, as a matter of
> fact, has undefined behavior.
>
> But, hey, this is C++, right? If we can make it more complicated, let=E2=
=80=99s!
>
> My faith in humanity is lost forever.
>
>
> I=E2=80=99m not quite as bleak as that, but close. After twenty-five year=
s of
> writing C++ on a daily basis, I am still spending a large part of my
> programming effort watching myself over my own shoulder, just to avoid
> shooting myself in the foot with something silly, such as forgetting to
> disable a copy constructor or accidentally relying on undefined evaluatio=
n
> order. It=E2=80=99s tedious, to say the least.
>
> And, after twenty-five years, I=E2=80=99m still unable to say that C++ is=
 easy. It
> isn=E2=80=99t, period. If performance doesn=E2=80=99t matter, give me Jav=
a or C# any day.
> (And, no, I=E2=80=99m not a Java weenie. But Java *is* easy, certainly wh=
en
> compared to C++.)
>
> Michi.
>
> PS: So, there, I=E2=80=99ve spoken the J-word. Now go and shoot 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/17BED39D-CD8=
6-42DA-8FD9-0448CA3C3407%40canonical.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17BED39D-CD=
86-42DA-8FD9-0448CA3C3407%40canonical.com?utm_medium=3Demail&utm_source=3Df=
ooter>
> .
>

--=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/CAKiZDp0rTikz9zYOCsgYosa9F%2BjxUROwsZc9aOYdsfui6=
xXu%2BA%40mail.gmail.com.

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

<div dir=3D"ltr">No shooting for using the =C2=ABJ=C2=BB word, at least not=
 from me.<br><br>@Miro : =C2=ABThey expect things to be evaluated from left=
 to right, because that is the order they typed it in. And it always works.=
 Except when it doesn&#39;t (but only in C/C++)=C2=BB. If my memory is corr=
ect, Lisp / Scheme evaluated functions right-to-left. It was/is a specified=
 order, though. C# mandates left-to-right. C++ and C state the relative ord=
ering of f() and g() in this expression is not something you should count o=
n. I think the position on relative ordering of a priori independent statem=
ents such as f() ad g() in something like =C2=ABfct(f(), g())=C2=BB is more=
 one of aesthetics than something sound; I was never taught, way back when =
that it would be a sensible thing to expect f() and g() to be ordered in a =
specific way, and I definitely don&#39;t think, even today, that writing co=
de that depends on such an ordering makes sense in general. If it works due=
 to this dependency, it&#39;s not an easy thing to maintain in the long run=
..<br><br>@Hyman : see above. I am sad that code gets broken due to expectan=
cies on the ordering of such statements, but I&#39;m saddened that such cod=
e was written in the first place. There might be good reasons to specifiy t=
he ordering of such statements in the standard, but fixing a priori broken =
code is not it, at least not in my mind. Should we impose an ordering, whic=
h we could, this use case would not (to me) be one of the reasons to suppor=
t the changed (it is reminescent, in a way, of some of the debates regardin=
g whether automating move semantics would ba a good thing since it would br=
eak classes with hidden invariants). I&#39;m not against your position that=
 specifying ordering could be a good thing, but I&#39;d look for another ex=
ample than this. If you have something where it would be useful for somethi=
ng else than code that was incorrect in the first place, I think it would b=
e useful, and I would like to know more about it.<br><br>@Michi : I don&#39=
;t think the fact that there is no a priori ordering of such statements mak=
es the language more complicated. Knowing they are unordered (could be done=
 in parallel should they be [[pure]] or whatever) or knowing they are manda=
ted to be evaluated in a specific order (right-to-left, left-to-right) seem=
s of equivalent complexity to me. Even if the ordering was mandated, I&#39;=
d avoid depending on it (if my company uses more than one programming langu=
age, porting an algorithm to other languages would be made unnecessarily co=
mplex due to this dependence; it&#39;s a very bad idea).<br><br>@Michi : th=
e dependency you are bringing forward is of another nature, being a data de=
pendency where the first line influences the second one in an ordered seque=
nce of instructions. I don&#39;t think anyone on this thread questions the =
idea of sequence per se, no matter what individual positions are.<br><br>In=
 a more general sense:<br><br><ul><li>things such as obj.f().g() do (to me)=
 make sense only as ((obj).f()).g(), so let&#39;s not do anything to break =
this</li><li>things such as obj.f(obj).g(obj.f()) make sense to me as respe=
cting =C2=ABparenthesis ordering=C2=BB as on the prior bullet</li><li>if f(=
) and g() have side-effects, then such expressions are just trouble. There&=
#39;s no ordering that would solve the deeper problems in a satisfactory ma=
nner (AFAIK)</li><li>we already have many weird cases such as =C2=ABcout &l=
t;&lt; f() &lt;&lt; g();=C2=BB not necessarily being equivalent as =C2=ABco=
ut &lt;&lt; f(); cout &lt;&lt; g();=C2=BB in the presence of side-effects i=
n f() and g(). The key problem is not the relative ordering of the function=
s, at least it does not seem so to me</li><li>if we are imposing an orderin=
g to fix such things, I think we&#39;re making a mistake</li></ul><br>Cheer=
s!<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-=
03-03 20:06 GMT-05:00 Michi Henning <span dir=3D"ltr">&lt;<a href=3D"mailto=
:michi.henning@canonical.com" target=3D"_blank">michi.henning@canonical.com=
</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:=
break-word"><div><span class=3D""><blockquote type=3D"cite"><div><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>They di=
dn&#39;t forget. They seem to have deliberately left it unspecified.</div><=
div><br></div><div>Source: <a href=3D"https://www.eskimo.com/~scs/cclass/no=
tes/sx7c.html" target=3D"_blank">https://www.eskimo.com/~scs/cclass/notes/s=
x7c.html</a></div><div><br></div><div>quote:=C2=A0<font color=3D"#ff0000"><=
span style=3D"font-family:&#39;Times New Roman&#39;;font-size:inherit">The =
moral is that writing code that depends on order of evaluation is a bad pro=
gramming practice in any language. Naturally, it is necessary to know what =
things to avoid, but if you don&#39;t know=C2=A0</span><i style=3D"font-fam=
ily:&#39;Times New Roman&#39;;font-size:inherit">how</i><span style=3D"font=
-family:&#39;Times New Roman&#39;;font-size:inherit">=C2=A0they are done on=
 various machines, you won&#39;t be tempted to take advantage of a particul=
ar implementation.</span>=C2=A0</font></div></div></div></div></div></block=
quote><div><br></div></span>I just dug out my 1st edition copy of K&amp;R a=
nd, yes, those words are indeed there (final para on page 50).</div><div><b=
r></div><div>To state that =E2=80=9Cwriting code that depends on order of e=
valuation is bad programming practice in any language=E2=80=9D is to make a=
 rather sweeping statement, and one that is contradicted by many modern lan=
guages. In K&amp;R=E2=80=99s defense, the statement was made almost 40 year=
s ago.</div><div><br></div><div>We use sequencing all the time. If I write<=
/div><div><br></div><div>a =3D b;</div><div>c +=3D 2 * a;</div><div><br></d=
iv><div>I=E2=80=99d be rather surprised if the compiler were to re-order th=
ese two statements. But, for some reason I can=E2=80=99t quite follow, doin=
g the same thing for expressions is considered bad, even though a complex e=
xpression is just a sequence of simple statements. Why anyone would deem it=
 desirable for things to be evaluated in any order is beyond me, hypothetic=
al compile-time optimizations notwithstanding.</div><div><br></div><div>The=
 second rationale strikes me as completely back to front:</div><div><br></d=
iv><div>=E2=80=9CIf you don=E2=80=99t know how they are done on various mac=
hines, you won=E2=80=99t be tempted to take advantage of a particular imple=
mentation.=E2=80=9D</div><div><br></div><div>The problem isn=E2=80=99t that=
 people are tempted to take advantage. The problem is that they write somet=
hing, test it, find that it works, and move on. All the while being blissfu=
lly ignorant that the working code, as a matter of fact, has undefined beha=
vior.</div><div><br></div><div>But, hey, this is C++, right? If we can make=
 it more complicated, let=E2=80=99s!</div><div><span class=3D""><br><blockq=
uote type=3D"cite"><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><div>My faith in humanity is lost forever.</div></div><=
/div></div></div></blockquote><div><br></div></span>I=E2=80=99m not quite a=
s bleak as that, but close. After twenty-five years of writing C++ on a dai=
ly basis, I am still spending a large part of my programming effort watchin=
g myself over my own shoulder, just to avoid shooting myself in the foot wi=
th something silly, such as forgetting to disable a copy constructor or acc=
identally relying on undefined evaluation order. It=E2=80=99s tedious, to s=
ay the least.</div><div><br></div><div>And, after twenty-five years, I=E2=
=80=99m still unable to say that C++ is easy. It isn=E2=80=99t, period. If =
performance doesn=E2=80=99t matter, give me Java or C# any day. (And, no, I=
=E2=80=99m not a Java weenie. But Java *is* easy, certainly when compared t=
o C++.)</div><div><br></div><div>Michi.</div><div><br></div><div>PS: So, th=
ere, I=E2=80=99ve spoken the J-word. Now go and shoot me :-)</div><div><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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/17BED39D-CD86-42DA-8FD9-0448CA3C3407%=
40canonical.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17BED39D-CD=
86-42DA-8FD9-0448CA3C3407%40canonical.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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0rTikz9zYOCsgYosa9F%2BjxUROwsZ=
c9aOYdsfui6xXu%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0rTikz=
9zYOCsgYosa9F%2BjxUROwsZc9aOYdsfui6xXu%2BA%40mail.gmail.com</a>.<br />

--001a11438eaaee92c8052d2ff5cc--

.

--Apple-Mail=_F94562A3-4C74-4057-A099-FBCEA411985A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 4 Mar 2016, at 12:34 , Patrice Roy <patricer@gmail.com> wrote:
>=20
> @Miro : =C2=ABThey expect things to be evaluated from left to right, beca=
use that is the order they typed it in. And it always works. Except when it=
 doesn't (but only in C/C++)=C2=BB. If my memory is correct, Lisp / Scheme =
evaluated functions right-to-left. It was/is a specified order, though. C# =
mandates left-to-right.

This isn=E2=80=99t about whether left-to-right is better than right-to-left=
.. Either work fine, because they are known a-priori and simple to understan=
d. Whether it=E2=80=99s C# or Lisp, there is exactly one and only one way f=
or an expression to behave.

> C++ and C state the relative ordering of f() and g() in this expression i=
s not something you should count on. I think the position on relative order=
ing of a priori independent statements such as f() ad g() in something like=
 =C2=ABfct(f(), g())=C2=BB is more one of aesthetics than something sound; =
I was never taught, way back when that it would be a sensible thing to expe=
ct f() and g() to be ordered in a specific way, and I definitely don't thin=
k, even today, that writing code that depends on such an ordering makes sen=
se in general. If it works due to this dependency, it's not an easy thing t=
o maintain in the long run.

I disagree that this is about aesthetics. It=E2=80=99s not about aesthetics=
, it=E2=80=99s about people. Programmers (yes, they are people) are subject=
 to all the same cognitive pitfalls and misconceptions as everyone else, no=
 matter how much they should know better. They are people, after all. When =
I write =E2=80=9Ca" followed by "b=E2=80=9D, my brain, no matter how hard I=
 might try to train myself otherwise, can play tricks on me and make me thi=
nk =E2=80=9Ca followed by b=E2=80=9D instead of =E2=80=9Cmaybe a first, or =
maybe b first=E2=80=9D.

The notation suggests an order, even though no order exists. That creates c=
ognitive friction and invites mistakes.

In C++, an expression with n terms has n! possible evaluation orders. In C#=
 and Lisp, an expression with n terms has exactly one evaluation order. To =
me, any argument stating that undefined order is just as simple as a define=
d order is completely off the rails.

> @Hyman : see above. I am sad that code gets broken due to expectancies on=
 the ordering of such statements, but I'm saddened that such code was writt=
en in the first place.

It is unbelievably easy to write such code, and to write it even as a very =
diligent programmer. This is especially true, when I am forced to work with=
 weird and wonderful legacy C++ APIs that were written by people who were, =
shall we say, less than competent. Such APIs quite often have innocent-look=
ing function calls that take a value and return a value and, it just so hap=
pens, have internal side effects as well, often unbeknownst to the caller. =
Calling such functions in an unexpected order causes havoc. And, to be sure=
 whether or not the functions are free of side-effects, I have to go and (r=
ecursively) read the source code of the API I have to call into in its enti=
rety, even though I couldn=E2=80=99t be less interested. (Documentation of =
side effects doesn=E2=80=99t help because most APIs don=E2=80=99t have docu=
mentation worth the electrons that are wasted for displaying the doc on a s=
creen.)

Also don=E2=80=99t tell me that people shouldn=E2=80=99t be writing such fu=
nctions. I agree, they shouldn=E2=80=99t. But the reality of many popular C=
 and C++ APIs out there is that they are full of such crimes. For an exampl=
e, just look at the OpenGL APIs, which are basically one gigantic side effe=
ct.

To me, insisting that f(g(), h()) should have undefined evaluation order is=
 the same thing as stating

 =E2=80=9CThough shalt not ever call more than one function without an inte=
rvening sequence point, unless you have read all of the code of all functio=
ns in their entirety, lest their side effects blow your leg off.=E2=80=9D

This is not helpful to programmers.

> @Michi : I don't think the fact that there is no a priori ordering of suc=
h statements makes the language more complicated. Knowing they are unordere=
d (could be done in parallel should they be [[pure]] or whatever) or knowin=
g they are mandated to be evaluated in a specific order (right-to-left, lef=
t-to-right) seems of equivalent complexity to me.

I strongly disagree with that. That=E2=80=99s because, intuitively and subc=
onsciously, my brain whispers to me =E2=80=9Cfirst a, then b=E2=80=9D, when=
 it sees f(a, b).

Providing a left-to-right guarantee is more ordered than providing an unord=
ered guarantee (bad pun intended).

> Even if the ordering was mandated, I'd avoid depending on it (if my compa=
ny uses more than one programming language, porting an algorithm to other l=
anguages would be made unnecessarily complex due to this dependence; it's a=
 very bad idea).

This particular argument is a red herring, in my opinion. If I have to port=
 an algorithm from one language to another, order of evaluation is typicall=
y a tenth-order issue, if that. There are far more important considerations=
 than evaluation order when porting from C to Java, or vice versa.

The argument is a red herring for another reason: when I port from Java to =
C++, if I blindly copy expressions, I implicitly rely on the defined evalua=
tion order in Java that doesn=E2=80=99t exist in C++. In other words, your =
objection is invalid because, whether C++ mandates left-to-right or unorder=
ed does not matter for porting from one language to another: C++ will be wr=
ong some of the time, regardless of which order it chooses.

> @Michi : the dependency you are bringing forward is of another nature, be=
ing a data dependency where the first line influences the second one in an =
ordered sequence of instructions. I don't think anyone on this thread quest=
ions the idea of sequence per se, no matter what individual positions are.

I didn=E2=80=99t think that anyone would mistake it for that. I came up wit=
h that example simply to illustrate the cognitive dissonance. In the statem=
ent case, what comes first is evaluated first. In the expression case, what=
 comes first might be evaluated first, last, or somewhere in the middle.

From a cognitive perspective, undefined evaluation order is much the same t=
hing as pit with spikes at the bottom: it causes problems because it goes a=
gainst the grain of how people think. Ergonomically, undefined evaluation o=
rder a train wreck.

This is also why I do not like the current proposal as it stands. It mandat=
es left-to-right for only a subset of expressions, meaning the already-comp=
lex rules of C++ have yet again become even more complex because, after thi=
s change, I can=E2=80=99t just remember that =E2=80=9Cevaluation order is u=
ndefined.=E2=80=9D Instead, I now have to remember that =E2=80=9Cevaluation=
 order is defined for the following cases, but not for any others=E2=80=9D.

If the proposal makes it through in its current form, our style guide will =
gain a new rule. It=E2=80=99ll read something like this (I=E2=80=99m not ma=
king this up, trust me):

=E2=80=9CDo not ever rely on evaluation order, even in cases where it is we=
ll defined. The rules of when evaluation order is defined are subtle, and a=
n innocent change to an expression can destroy any previously well-defined =
order. Therefore, it is safest to not ever rely on evaluation order at all.=
=E2=80=9D

And so we blissfully follow down the path of ever-increasing complexity, an=
d wonder why it is so hard to hire good C++ programmers.

Cheers,

Michi.

--=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/209F1417-FF50-492B-A294-26026558AA8E%40canonical=
..com.

--Apple-Mail=_F94562A3-4C74-4057-A099-FBCEA411985A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 4 Mar 2016, at 12=
:34 , Patrice Roy &lt;<a href=3D"mailto:patricer@gmail.com" class=3D"">patr=
icer@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline">=
<div class=3D""><div dir=3D"ltr" class=3D"">@Miro : =C2=ABThey expect thing=
s to be evaluated from left to right, because that is the order they typed =
it in. And it always works. Except when it doesn't (but only in C/C++)=C2=
=BB. If my memory is correct, Lisp / Scheme evaluated functions right-to-le=
ft. It was/is a specified order, though. C# mandates left-to-right.</div></=
div></blockquote><div><br class=3D""></div><div><div>This isn=E2=80=99t abo=
ut whether left-to-right is better than right-to-left. Either work fine, be=
cause they are known a-priori and simple to understand. Whether it=E2=80=99=
s C# or Lisp, there is exactly one and only one way for an expression to be=
have.</div></div><br class=3D""><blockquote type=3D"cite" class=3D""><div c=
lass=3D""><div dir=3D"ltr" class=3D""> C++ and C state the relative orderin=
g of f() and g() in this expression is not something you should count on. I=
 think the position on relative ordering of a priori independent statements=
 such as f() ad g() in something like =C2=ABfct(f(), g())=C2=BB is more one=
 of aesthetics than something sound; I was never taught, way back when that=
 it would be a sensible thing to expect f() and g() to be ordered in a spec=
ific way, and I definitely don't think, even today, that writing code that =
depends on such an ordering makes sense in general. If it works due to this=
 dependency, it's not an easy thing to maintain in the long run.<br class=
=3D""></div></div></blockquote><div><br class=3D""></div></div><div>I disag=
ree that this is about aesthetics. It=E2=80=99s not about aesthetics, it=E2=
=80=99s about people. Programmers (yes, they are people) are subject to all=
 the same cognitive pitfalls and misconceptions as everyone else, no matter=
 how much they should know better. They are people, after all. When I write=
 =E2=80=9Ca" followed by "b=E2=80=9D, my brain, no matter how hard I might =
try to train myself otherwise, can play tricks on me and make me think =E2=
=80=9Ca followed by b=E2=80=9D instead of =E2=80=9Cmaybe a first, or maybe =
b first=E2=80=9D.</div><div><br class=3D""></div><div>The notation suggests=
 an order, even though no order exists. That creates cognitive friction and=
 invites mistakes.</div><div><br class=3D""></div><div>In C++, an expressio=
n with <i class=3D"">n</i> terms has <i class=3D"">n</i>! possible evaluati=
on orders. In C# and Lisp, an expression with <i class=3D"">n</i> terms has=
 exactly one evaluation order. To me, any argument stating that undefined o=
rder is just as simple as a defined order is completely off the rails.</div=
><div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><=
div dir=3D"ltr" class=3D"">@Hyman : see above. I am sad that code gets brok=
en due to expectancies on the ordering of such statements, but I'm saddened=
 that such code was written in the first place.</div></div></blockquote><di=
v><br class=3D""></div>It is unbelievably easy to write such code, and to w=
rite it even as a very diligent programmer. This is especially true, when I=
 am forced to work with weird and wonderful legacy C++ APIs that were writt=
en by people who were, shall we say, less than competent. Such APIs quite o=
ften have innocent-looking function calls that take a value and return a va=
lue and, it just so happens, have internal side effects as well, often unbe=
knownst to the caller. Calling such functions in an unexpected order causes=
 havoc. And, to be sure whether or not the functions are free of side-effec=
ts, I have to go and (recursively) read the source code of the API I have t=
o call into in its entirety, even though I couldn=E2=80=99t be less interes=
ted. (Documentation of side effects doesn=E2=80=99t help because most APIs =
don=E2=80=99t have documentation worth the electrons that are wasted for di=
splaying the doc on a screen.)</div><div><br class=3D""></div><div>Also don=
=E2=80=99t tell me that people shouldn=E2=80=99t be writing such functions.=
 I agree, they shouldn=E2=80=99t. But the reality of many popular C and C++=
 APIs out there is that they are full of such crimes. For an example, just =
look at the OpenGL APIs, which are basically one gigantic side effect.</div=
><div><br class=3D""></div><div>To me, insisting that f(g(), h()) should ha=
ve undefined evaluation order is the same thing as stating</div><div><br cl=
ass=3D""></div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre=
"> </span>=E2=80=9CThough shalt not ever call more than one function withou=
t an intervening sequence point, unless you have read all of the code of al=
l functions in their entirety, lest their side effects blow your leg off.=
=E2=80=9D</div><div><br class=3D""></div><div>This is not helpful to progra=
mmers.</div><div><br class=3D""><blockquote type=3D"cite" class=3D""><div c=
lass=3D""><div dir=3D"ltr" class=3D"">@Michi : I don't think the fact that =
there is no a priori ordering of such statements makes the language more co=
mplicated. Knowing they are unordered (could be done in parallel should the=
y be [[pure]] or whatever) or knowing they are mandated to be evaluated in =
a specific order (right-to-left, left-to-right) seems of equivalent complex=
ity to me.</div></div></blockquote><div><br class=3D""></div>I strongly dis=
agree with that. That=E2=80=99s because, intuitively and subconsciously, my=
 brain whispers to me =E2=80=9Cfirst a, then b=E2=80=9D, when it sees f(a, =
b).</div><div><br class=3D""></div><div>Providing a left-to-right guarantee=
 is more ordered than providing an unordered guarantee (bad pun intended).<=
/div><div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D=
""><div dir=3D"ltr" class=3D""> Even if the ordering was mandated, I'd avoi=
d depending on it (if my company uses more than one programming language, p=
orting an algorithm to other languages would be made unnecessarily complex =
due to this dependence; it's a very bad idea).<br class=3D""></div></div></=
blockquote><div><br class=3D""></div>This particular argument is a red herr=
ing, in my opinion. If I have to port an algorithm from one language to ano=
ther, order of evaluation is typically a tenth-order issue, if that. There =
are far more important considerations than evaluation order when porting fr=
om C to Java, or vice versa.</div><div><br class=3D""></div><div>The argume=
nt is a red herring for another reason: when I port from Java to C++, if I =
blindly copy expressions, I implicitly rely on the defined evaluation order=
 in Java that doesn=E2=80=99t exist in C++. In other words, your objection =
is invalid because, whether C++ mandates left-to-right or unordered does no=
t matter for porting from one language to another: C++ will be wrong some o=
f the time, regardless of which order it chooses.</div><div><br class=3D"">=
<blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=
=3D"">@Michi : the dependency you are bringing forward is of another nature=
, being a data dependency where the first line influences the second one in=
 an ordered sequence of instructions. I don't think anyone on this thread q=
uestions the idea of sequence per se, no matter what individual positions a=
re.<br class=3D""></div></div></blockquote><div><br class=3D""></div>I didn=
=E2=80=99t think that anyone would mistake it for that. I came up with that=
 example simply to illustrate the cognitive dissonance. In the statement ca=
se, what comes first is evaluated first. In the expression case, what comes=
 first might be evaluated first, last, or somewhere in the middle.</div><di=
v><br class=3D""></div><div>From a cognitive perspective, undefined evaluat=
ion order is much the same thing as pit with spikes at the bottom: it cause=
s problems because it goes against the grain of how people think. Ergonomic=
ally, undefined evaluation order a train wreck.</div><div><br class=3D""></=
div><div>This is also why I do not like the current proposal as it stands. =
It mandates left-to-right for only a subset of expressions, meaning the alr=
eady-complex rules of C++ have yet again become even more complex because, =
after this change, I can=E2=80=99t just remember that =E2=80=9Cevaluation o=
rder is undefined.=E2=80=9D Instead, I now have to remember that =E2=80=9Ce=
valuation order is defined for the following cases, but not for any others=
=E2=80=9D.</div><div><br class=3D""></div><div>If the proposal makes it thr=
ough in its current form, our style guide will gain a new rule. It=E2=80=99=
ll read something like this (I=E2=80=99m not making this up, trust me):</di=
v><div><br class=3D""></div><div>=E2=80=9CDo not ever rely on evaluation or=
der, even in cases where it is well defined. The rules of when evaluation o=
rder is defined are subtle, and an innocent change to an expression can des=
troy any previously well-defined order. Therefore, it is safest to not ever=
 rely on evaluation order at all.=E2=80=9D</div><div><br class=3D""></div><=
div>And so we blissfully follow down the path of ever-increasing complexity=
, and wonder why it is so hard to hire good C++ programmers.</div><div><br =
class=3D""></div><div>Cheers,</div><div><br class=3D""></div><div>Michi.</d=
iv><div><br class=3D""></div></body></html>

<p></p>

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

--Apple-Mail=_F94562A3-4C74-4057-A099-FBCEA411985A--

.

On 2016-03-04 04:30, Michi Henning wrote:
> In C++, an expression with /n/ terms has /n/! possible evaluation
> orders.

I disagree:
  - comma operators provide ordering (reducing the number)
  - value computations and side effects can be arbitrarily interleaved
among unordered subexpressions (increasing the number)

Jens

--
You received this message because you are 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/56D90584.4040403%40gmx.net.

.

--Apple-Mail=_F7585E4D-912A-48F6-801F-01E61B427B7C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 4 Mar 2016, at 13:48 , Jens Maurer <Jens.Maurer@gmx.net> wrote:
>=20
> On 2016-03-04 04:30, Michi Henning wrote:
>> In C++, an expression with /n/ terms has /n/! possible evaluation
>> orders.
>=20
> I disagree:
> - comma operators provide ordering (reducing the number)
> - value computations and side effects can be arbitrarily interleaved
> among unordered subexpressions (increasing the number)

Yes.

I was absolutely sure that there would be an exception to the n! example. I=
t wouldn=E2=80=99t be C++ otherwise.

Michi.

--=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/392CC4F7-2EF0-4E1C-BBD9-88B3DE475AB7%40canonical=
..com.

--Apple-Mail=_F7585E4D-912A-48F6-801F-01E61B427B7C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 4 Mar 2016, at 13=
:48 , Jens Maurer &lt;<a href=3D"mailto:Jens.Maurer@gmx.net" class=3D"">Jen=
s.Maurer@gmx.net</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline=
"><div class=3D""><div class=3D"">On 2016-03-04 04:30, Michi Henning wrote:=
<br class=3D""><blockquote type=3D"cite" class=3D"">In C++, an expression w=
ith /n/ terms has /n/! possible evaluation<br class=3D"">orders.<br class=
=3D""></blockquote><br class=3D"">I disagree:<br class=3D""> - comma operat=
ors provide ordering (reducing the number)<br class=3D""> - value computati=
ons and side effects can be arbitrarily interleaved<br class=3D"">among uno=
rdered subexpressions (increasing the number)<br class=3D""></div></div></b=
lockquote><div><br class=3D""></div>Yes.</div><div><br class=3D""></div><di=
v>I was absolutely sure that there would be an exception to the <i class=3D=
"">n</i>! example. It wouldn=E2=80=99t be C++ otherwise.</div><div><br clas=
s=3D""></div><div>Michi.</div></body></html>

<p></p>

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

--Apple-Mail=_F7585E4D-912A-48F6-801F-01E61B427B7C--

.

Am 04.03.2016 um 03:34 schrieb Patrice Roy:
> No shooting for using the =C2=ABJ=C2=BB word, at least not from me.
>
> @Miro : =C2=ABThey expect things to be evaluated from left to right,=20
> because that is the order they typed it in. And it always works.=20
> Except when it doesn't (but only in C/C++)=C2=BB. If my memory is correct=
,=20
> Lisp / Scheme evaluated functions right-to-left. It was/is a specified=20
> order, though. C# mandates left-to-right.
Common Lisp evaluation order is specified as left-to-right.
> C++ and C state the relative ordering of f() and g() in this=20
> expression is not something you should count on.
Of course you *shouldn't* count on it, because it is bloody undefined.=20
But students *don't know that*. Details like evaluation order and other=20
nuances of C++ are not touched upon at this stage of teaching because=20
they'd just make peoples' heads explode. When students do exercises on=20
their own at home they run into these problems all the time because they=20
don't have the experience, they don't have the knowledge and therefore=20
they inadvertently write code that has such issues. They waste hours=20
researching and bug hunting and when they finally figure out that the=20
expression f(a, b) they wrote down is evaluated in the wrong order=20
(*wrong* as in defying their expectations, and even worse, they *can't=20
even know* the actual order) they conclude that C++ is the worst=20
language in existence and switch to a different class. That is all made=20
worse by the fact that even seasoned C++ developers with 30+ years of=20
experience make these mistakes and such code passes reviews, and some of=20
those experts turn out to be professors. If even their professor doesn't=20
know the answer right away, then who does?
> I think the position on relative ordering of a priori independent=20
> statements such as f() ad g() in something like =C2=ABfct(f(), g())=C2=BB=
 is=20
> more one of aesthetics than something sound; I was never taught, way=20
> back when that it would be a sensible thing to expect f() and g() to=20
> be ordered in a specific way, and I definitely don't think, even=20
> today, that writing code that depends on such an ordering makes sense=20
> in general. If it works due to this dependency, it's not an easy thing=20
> to maintain in the long run.
People have wildly different expectations, and that largely depends on=20
what they start programming with. And people who have never programmed=20
before usually have expectations that have no connection to the=20
technical reality. Those who grow up speaking and writing a=20
left-to-right language have it ingrained in their head that all=20
sequences of things are let-to-right as that is the direction they read=20
and write in. In math class they are given the exercise f(g(x) + h(x))=20
and how do they intuitively solve it? They calculate a=3Dg(x) first, then=
=20
b=3Dh(x), then c=3Da+b, then f(c). Try getting rid of this intuition after=
=20
applying it for several years during the phase of your live where the=20
brain solidifies such patterns. They expect the programming language to=20
work the same because programming and math are very closely related, and=20
all the modern languages actually *do* fulfill this expectation.

I cannot speak for those who grow up with a right-to-left language and I=20
am curious how they think about it, and especially whether they type=20
code in left-to-right or right-to-left order.

Regardless, the thing is: order is easier to teach and understand than=20
chaos. If you want to bring people into programming you have to give=20
them confidence in the code they are writing. Telling them "yeah I know=20
you wrote down this here but that's not what's going to happen" is a=20
really good deterrent.

> @Hyman : see above. I am sad that code gets broken due to expectancies=20
> on the ordering of such statements, but I'm saddened that such code=20
> was written in the first place.
Can you in all honesty say that you have *never* been in the situation=20
where time was wasted hunting down a bug that was caused by wrong order=20
of evaluation but the idea didn't occur to anybody until way too much=20
time had passed? It is always seasy to state one "would never write such=20
code" after the fact.

--=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/56D90FA8.9050009%40gmail.com.

.

--047d7b3a9b3a159680052d32fd0a
Content-Type: text/plain; charset=UTF-8

On 4 Mar 2016 02:10, "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
> There's nothing to expand upon.  It's as simple as I have always
maintained.  Unspecified behavior allows latent errors to linger in code
for years, becoming exposed only when something in the compilation
environment changes.

The core language or library contain plenty of instances of unspecified or
undefined behavior; if you rely on a particular behavior that makes it your
responsibility to check when you change compiler version or options.

>> requesting warning diagnostics for code depending on evaluation order
>
> This is impossible to use, because it would generate warnings on every
expression involving more than one unsequenced function call.

I think it should be possible to make it work, only warning when the
compiler can prove (after inlining) that the result or side effect of an
expression is order-dependent for at least one input. It would certainly be
possible to warn if constexpr evaluation has more than one possible result
(currently afaict such a program is well-formed).

>> or requesting vendor compatibility modes (-fltr and -frtl, say, along
the lines of -fwrapv, or equivalent pragmas for finer-grained control).
>
> I don't believe such modes have been notably successful.  The
floating-point accuracy ones, for example, are horrible. And see below,

If they haven't been successful, it's because - contrary to the claim of
people like you - there isn't actually sufficient demand for such
compatibility modes.

>> If you can't or won't change any of your code, I can't see why -fltr
shouldn't be a satisfactory option - and if it really is the superior
choice, then in a few years everyone will be using it and mandating it can
be considered.
>
> It's not satisfactory because our code runs on several different
platforms, using several different compilers.  We would need all of them to
support this option, and since we support legacy platforms (e.g., AIX and
SunOS), that is difficult.  If it were part of the standard, it would be
more likely to show up everywhere.

Why? Use it with compilers that support it; for legacy compilers you can
assume that they will never change their evaluation behavior anyway. They
certainly won't change to support a new version of the standard.

> And how could you possibly measure "better" in this context?  It's a
change which will be almost entirely undetectable.  It's effect will be to
prevent people from writing code that accidentally works but actually has
unspecified behavior.  It's like asking to measure the effects of having a
guardian angel - how do you measure the number of accidents that never
happen?

By popularity. If -fltr is something that the world has been screaming out
for, then projects, build systems, IDEs and educators will adopt it
immediately and only a few hold outs will continue to prefer unspecified
order.

> But regardless, the point is that having unspecified order of evaluation
is bad for the C++ language and bad for C++ programmers.  I'm not just
searching for a way to immunize my code from this poor decision, I want
this poor decision removed from the language so that no one needs to suffer
from it.

Instead you will make programmers on green-field and well-maintained code
bases pay for your code debt? No thanks.

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

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

<p dir=3D"ltr"><br>
On 4 Mar 2016 02:10, &quot;Hyman Rosen&quot; &lt;<a href=3D"mailto:hyman.ro=
sen@gmail.com">hyman.rosen@gmail.com</a>&gt; wrote:<br>
&gt; There&#39;s nothing to expand upon.=C2=A0 It&#39;s as simple as I have=
 always maintained.=C2=A0 Unspecified behavior allows latent errors to ling=
er in code for years, becoming exposed only when something in the compilati=
on environment changes.</p>
<p dir=3D"ltr">The core language or library contain plenty of instances of =
unspecified or undefined behavior; if you rely on a particular behavior tha=
t makes it your responsibility to check when you change compiler version or=
 options. </p>
<p dir=3D"ltr">&gt;&gt; requesting warning diagnostics for code depending o=
n evaluation order<br>
&gt;<br>
&gt; This is impossible to use, because it would generate warnings on every=
 expression involving more than one unsequenced function call.</p>
<p dir=3D"ltr">I think it should be possible to make it work, only warning =
when the compiler can prove (after inlining) that the result or side effect=
 of an expression is order-dependent for at least one input. It would certa=
inly be possible to warn if constexpr evaluation has more than one possible=
 result (currently afaict such a program is well-formed). </p>
<p dir=3D"ltr">&gt;&gt; or requesting vendor compatibility modes (-fltr and=
 -frtl, say, along the lines of -fwrapv, or equivalent pragmas for finer-gr=
ained control).<br>
&gt;<br>
&gt; I don&#39;t believe such modes have been notably successful.=C2=A0 The=
 floating-point accuracy ones, for example, are horrible. And see below,</p=
>
<p dir=3D"ltr">If they haven&#39;t been successful, it&#39;s because - cont=
rary to the claim of people like you - there isn&#39;t actually sufficient =
demand for such compatibility modes. </p>
<p dir=3D"ltr">&gt;&gt; If you can&#39;t or won&#39;t change any of your co=
de, I can&#39;t see why -fltr shouldn&#39;t be a satisfactory option - and =
if it really is the superior choice, then in a few years everyone will be u=
sing it and mandating it can be considered.<br>
&gt;<br>
&gt; It&#39;s not satisfactory because our code runs on several different p=
latforms, using several different compilers.=C2=A0 We would need all of the=
m to support this option, and since we support legacy platforms (e.g., AIX =
and SunOS), that is difficult.=C2=A0 If it were part of the standard, it wo=
uld be more likely to show up everywhere.=C2=A0 </p>
<p dir=3D"ltr">Why? Use it with compilers that support it; for legacy compi=
lers you can assume that they will never change their evaluation behavior a=
nyway. They certainly won&#39;t change to support a new version of the stan=
dard. </p>
<p dir=3D"ltr">&gt; And how could you possibly measure &quot;better&quot; i=
n this context?=C2=A0 It&#39;s a change which will be almost entirely undet=
ectable.=C2=A0 It&#39;s effect will be to prevent people from writing code =
that accidentally works but actually has unspecified behavior.=C2=A0 It&#39=
;s like asking to measure the effects of having a guardian angel - how do y=
ou measure the number of accidents that never happen?</p>
<p dir=3D"ltr">By popularity. If -fltr is something that the world has been=
 screaming out for, then projects, build systems, IDEs and educators will a=
dopt it immediately and only a few hold outs will continue to prefer unspec=
ified order. </p>
<p dir=3D"ltr">&gt; But regardless, the point is that having unspecified or=
der of evaluation is bad for the C++ language and bad for C++ programmers.=
=C2=A0 I&#39;m not just searching for a way to immunize my code from this p=
oor decision, I want this poor decision removed from the language so that n=
o one needs to suffer from it.</p>
<p dir=3D"ltr">Instead you will make programmers on green-field and well-ma=
intained code bases pay for your code debt? No thanks. </p>

<p></p>

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

--047d7b3a9b3a159680052d32fd0a--

.

--Apple-Mail=_D6AA5537-3756-43C6-B721-34807624726E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> Instead you will make programmers on green-field and well-maintained code=
 bases pay for your code debt? No thanks.
>=20

How would that penalise other programmers? Sorry, I don=E2=80=99t follow, c=
an you explain?

Cheers,

Michi.

--=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/DD19BD4F-F009-4556-A8E8-C8B5A3AE1633%40canonical=
..com.

--Apple-Mail=_D6AA5537-3756-43C6-B721-34807624726E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">Instead y=
ou will make programmers on green-field and well-maintained code bases pay =
for your code debt? No thanks. </p></div></blockquote><div><br class=3D""><=
/div>How would that penalise other programmers? Sorry, I don=E2=80=99t foll=
ow, can you explain?</div><div><br class=3D""></div><div>Cheers,</div><div>=
<br class=3D""></div><div>Michi.</div></body></html>

<p></p>

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

--Apple-Mail=_D6AA5537-3756-43C6-B721-34807624726E--

.

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

On 4 Mar 2016 14:13, "Michi Henning" <michi.henning@canonical.com> wrote:
>>
>> Instead you will make programmers on green-field and well-maintained
code bases pay for your code debt? No thanks.
>
>
> How would that penalise other programmers? Sorry, I don=E2=80=99t follow,=
 can you
explain?
>

Code written to a defined evaluation order is less expressive; one cannot
know whether a particular order is intended or whether any order is OK. It
is less efficient, because certain code transformations (to reduce data
dependencies, e.g.) and parallelisations are excluded. It is less
maintainable, because one cannot reorder function arguments when changing
APIs, reorder subexpressions, or merge changes without having to consider
all possible side effects.

And I should also have mentioned programmers whose code assumes RTL
evaluation order; I don't feel any particular identification with them, but
would point out that your proposed change massively privileges your code
debt over theirs.

--=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/CAJnLdOZJv_u_ve5upGzaRG9urefN_muCyHkUWE9tTCT3gO3=
p3w%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 4 Mar 2016 14:13, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Instead you will make programmers on green-field and well-maintain=
ed code bases pay for your code debt? No thanks.<br>
&gt;<br>
&gt;<br>
&gt; How would that penalise other programmers? Sorry, I don=E2=80=99t foll=
ow, can you explain?<br>
&gt;</p>
<p dir=3D"ltr">Code written to a defined evaluation order is less expressiv=
e; one cannot know whether a particular order is intended or whether any or=
der is OK. It is less efficient, because certain code transformations (to r=
educe data dependencies, e.g.) and parallelisations are excluded. It is les=
s maintainable, because one cannot reorder function arguments when changing=
 APIs, reorder subexpressions, or merge changes without having to consider =
all possible side effects. </p>
<p dir=3D"ltr">And I should also have mentioned programmers whose code assu=
mes RTL evaluation order; I don&#39;t feel any particular identification wi=
th them, but would point out that your proposed change massively privileges=
 your code debt over theirs. </p>

<p></p>

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

--001a1140f750926bbf052d335b68--

.

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

On 4 Mar 2016 11:30, "Michi Henning" <michi.henning@canonical.com> wrote:
>
> If the proposal makes it through in its current form, our style guide
will gain a new rule. It=E2=80=99ll read something like this (I=E2=80=99m n=
ot making this
up, trust me):
>
> =E2=80=9CDo not ever rely on evaluation order, even in cases where it is =
well
defined. The rules of when evaluation order is defined are subtle, and an
innocent change to an expression can destroy any previously well-defined
order. Therefore, it is safest to not ever rely on evaluation order at all.=
=E2=80=9D
>

Your style guide doesn't contain such a rule already? No wonder you have
problems attracting good 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/CAJnLdOY7%3DdSA3xRo-zCVr-8Y-BYmQjtwOxhu6BS3JrRfy=
apyRA%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 4 Mar 2016 11:30, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;<br>
&gt; If the proposal makes it through in its current form, our style guide =
will gain a new rule. It=E2=80=99ll read something like this (I=E2=80=99m n=
ot making this up, trust me):<br>
&gt;<br>
&gt; =E2=80=9CDo not ever rely on evaluation order, even in cases where it =
is well defined. The rules of when evaluation order is defined are subtle, =
and an innocent change to an expression can destroy any previously well-def=
ined order. Therefore, it is safest to not ever rely on evaluation order at=
 all.=E2=80=9D<br>
&gt;</p>
<p dir=3D"ltr">Your style guide doesn&#39;t contain such a rule already? No=
 wonder you have problems attracting good programmers. </p>

<p></p>

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

--001a113ecbe40b1b63052d3377a7--

.

On 4 March 2016 at 06:31, Miro Knejp <miro.knejp@gmail.com> wrote:
>> @Miro : =C2=ABThey expect things to be evaluated from left to right, bec=
ause
>> that is the order they typed it in. And it always works. Except when it
>> doesn't (but only in C/C++)=C2=BB. If my memory is correct, Lisp / Schem=
e
>> evaluated functions right-to-left. It was/is a specified order, though. =
C#
>> mandates left-to-right.
>
> Common Lisp evaluation order is specified as left-to-right.


Except when it isn't, consider the difference between LET and LET*,
and PROG and PROG*.
Common Lisp specifies the order in some places but leaves it
unspecified in others, and
there's plenty of existing code that relies on both the sequential
order and the lack of it.

--=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/CAFk2RUbmU7Fj1w_pScDmHp%3D%2Bw9bRzNjnasevd3M1c8j=
2y%3DXk7Q%40mail.gmail.com.

.

--Apple-Mail=_8A6D7D8C-1C39-4EB6-BA4A-337DD2430FD1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> Code written to a defined evaluation order is less expressive; one cannot=
 know whether a particular order is intended or whether any order is OK.
>=20
Well, with what we have now, if there is anything in an expression that has=
 a side effect, I don=E2=80=99t know whether this is intended or not either=
.. That=E2=80=99s assuming that I can even see the side effect. Otherwise, i=
f there are no side effects, I guess I know that any order is OK.
> It is less efficient, because certain code transformations (to reduce dat=
a dependencies, e.g.) and parallelisations are excluded.
>=20
I would have thought that, in many cases, the compiler could still re-order=
 under an as-if rule.
> It is less maintainable, because one cannot reorder function arguments wh=
en changing APIs, reorder subexpressions, or merge changes without having t=
o consider all possible side effects.
>=20
Yes, that=E2=80=99s the price of side effects, not evaluation order. Any si=
de effects that might happen are just as damaging now as they would be with=
 left-to-right evaluation. Because, right now, any order can happen. So, an=
y reordering right now is potentially just as damaging as any re-ordering u=
nder a left-to-right rule. So, unless I=E2=80=99m missing something, I thin=
k this point is a red herring.
> And I should also have mentioned programmers whose code assumes RTL evalu=
ation order; I don't feel any particular identification with them, but woul=
d point out that your proposed change massively privileges your code debt o=
ver theirs.
>=20

What code debt? Sorry, I=E2=80=99m just not following. How can left-to-righ=
t disadvantage or privilege anyone, given that, currently, there no defined=
 order whatsoever?

Michi.

--=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/CF161C33-A74D-465C-9FEF-3B03DE5AC99A%40canonical=
..com.

--Apple-Mail=_8A6D7D8C-1C39-4EB6-BA4A-337DD2430FD1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">Code writ=
ten to a defined evaluation order is less expressive; one cannot know wheth=
er a particular order is intended or whether any order is OK.</p></div></bl=
ockquote><div>Well, with what we have now, if there is anything in an expre=
ssion that has a side effect, I don=E2=80=99t know whether this is intended=
 or not either. That=E2=80=99s assuming that I can even see the side effect=
.. Otherwise, if there are no side effects, I guess I know that any order is=
 OK.</div><blockquote type=3D"cite" class=3D""><div class=3D""><p dir=3D"lt=
r" class=3D""> It is less efficient, because certain code transformations (=
to reduce data dependencies, e.g.) and parallelisations are excluded.</p></=
div></blockquote><div>I would have thought that, in many cases, the compile=
r could still re-order under an as-if rule.</div><blockquote type=3D"cite" =
class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">It is less maintainabl=
e, because one cannot reorder function arguments when changing APIs, reorde=
r subexpressions, or merge changes without having to consider all possible =
side effects. </p></div></blockquote><div>Yes, that=E2=80=99s the price of =
side effects, not evaluation order. Any side effects that might happen are =
just as damaging now as they would be with left-to-right evaluation. Becaus=
e, right now, any order can happen. So, any reordering right now is potenti=
ally just as damaging as any re-ordering under a left-to-right rule. So, un=
less I=E2=80=99m missing something, I think this point is a red herring.</d=
iv><blockquote type=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" clas=
s=3D"">And I should also have mentioned programmers whose code assumes RTL =
evaluation order; I don't feel any particular identification with them, but=
 would point out that your proposed change massively privileges your code d=
ebt over theirs. </p></div></blockquote><div><br class=3D""></div>What code=
 debt? Sorry, I=E2=80=99m just not following. How can left-to-right disadva=
ntage or privilege anyone, given that, currently, there no defined order wh=
atsoever?</div><div><br class=3D""></div><div>Michi.</div><div><br class=3D=
""></div></body></html>

<p></p>

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

--Apple-Mail=_8A6D7D8C-1C39-4EB6-BA4A-337DD2430FD1--

.

--Apple-Mail=_1CC00EB8-22C3-4E24-987C-E4363080C7F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> > =E2=80=9CDo not ever rely on evaluation order, even in cases where it i=
s well defined. The rules of when evaluation order is defined are subtle, a=
nd an innocent change to an expression can destroy any previously well-defi=
ned order. Therefore, it is safest to not ever rely on evaluation order at =
all.=E2=80=9D
> >
>=20
> Your style guide doesn't contain such a rule already? No wonder you have =
problems attracting good programmers.
>=20

No, it currently doesn=E2=80=99t have a such rule. Because, as lots of peop=
le keep assuring me, it=E2=80=99s understood that evaluation order is undef=
ined and that there is no problem with that. So, why would there be a style=
 rule? After all, everyone knows that only stupid programmers write order-d=
ependent expressions, and we don=E2=80=99t hire stupid programmers.

Michi.

--=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/EBF07C10-999F-4CE0-B7EB-8198DF15B1A5%40canonical=
..com.

--Apple-Mail=_1CC00EB8-22C3-4E24-987C-E4363080C7F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">&gt; =E2=
=80=9CDo not ever rely on evaluation order, even in cases where it is well =
defined. The rules of when evaluation order is defined are subtle, and an i=
nnocent change to an expression can destroy any previously well-defined ord=
er. Therefore, it is safest to not ever rely on evaluation order at all.=E2=
=80=9D<br class=3D"">
&gt;</p><p dir=3D"ltr" class=3D"">Your style guide doesn't contain such a r=
ule already? No wonder you have problems attracting good programmers. </p><=
/div></blockquote><div><br class=3D""></div>No, it currently doesn=E2=80=99=
t have a such rule. Because, as lots of people keep assuring me, it=E2=80=
=99s understood that evaluation order is undefined and that there is no pro=
blem with that. So, why would there be a style rule? After all, everyone kn=
ows that only stupid programmers write order-dependent expressions, and we =
don=E2=80=99t hire stupid programmers.</div><div><br class=3D""></div><div>=
Michi.</div></body></html>

<p></p>

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

--Apple-Mail=_1CC00EB8-22C3-4E24-987C-E4363080C7F9--

.

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

On 4 Mar 2016 15:25, "Michi Henning" <michi.henning@canonical.com> wrote:
>>
>> Code written to a defined evaluation order is less expressive; one
cannot know whether a particular order is intended or whether any order is
OK.
>
> Well, with what we have now, if there is anything in an expression that
has a side effect, I don=E2=80=99t know whether this is intended or not eit=
her.
That=E2=80=99s assuming that I can even see the side effect. Otherwise, if =
there
are no side effects, I guess I know that any order is OK.

That's not what I meant. Right now, it is easy to write code where side
effects must be sequenced: use semicolon, comma operator or logical
operators. It is also easy to write code where side effects can occur in
any order: combine them into a single expression not using the sequencing
operators. Under the proposal, the latter would be impossible to express.

>> It is less efficient, because certain code transformations (to reduce
data dependencies, e.g.) and parallelisations are excluded.
>
> I would have thought that, in many cases, the compiler could still
re-order under an as-if rule.

Often, yes, but the more interesting cases are where an intervening
function call is not available or not known. And there are cases where the
compiler would have to consider possible aliasing of data pointers that can
be ignored under a transformed code.

>> It is less maintainable, because one cannot reorder function arguments
when changing APIs, reorder subexpressions, or merge changes without having
to consider all possible side effects.
>
> Yes, that=E2=80=99s the price of side effects, not evaluation order. Any =
side
effects that might happen are just as damaging now as they would be with
left-to-right evaluation. Because, right now, any order can happen. So, any
reordering right now is potentially just as damaging as any re-ordering
under a left-to-right rule. So, unless I=E2=80=99m missing something, I thi=
nk this
point is a red herring.

Not all side effects need to be ordered. I suppose this is a corollary of
the first point; if there is a way to express that any side effects can
occur in any order then that part of the program is more amenable to
refactoring.

>> And I should also have mentioned programmers whose code assumes RTL
evaluation order; I don't feel any particular identification with them, but
would point out that your proposed change massively privileges your code
debt over theirs.
>
>
> What code debt? Sorry, I=E2=80=99m just not following. How can left-to-ri=
ght
disadvantage or privilege anyone, given that, currently, there no defined
order whatsoever?

Respondents have described code that silently depends on LTR. Given that
some implementations have used RTL, there must be some legacy code in
existence that assumes RTL. This would break under compulsory LTR, whereas
it can continue to work under the current dispensation, either by turning
down optimization or via compatibility flags.

--=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/CAJnLdOYe1NROhkGzVp9Bef3KeOJPnUuRsJb4M3jrtwNoaTb=
DKQ%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 4 Mar 2016 15:25, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Code written to a defined evaluation order is less expressive; one=
 cannot know whether a particular order is intended or whether any order is=
 OK.<br>
&gt;<br>
&gt; Well, with what we have now, if there is anything in an expression tha=
t has a side effect, I don=E2=80=99t know whether this is intended or not e=
ither. That=E2=80=99s assuming that I can even see the side effect. Otherwi=
se, if there are no side effects, I guess I know that any order is OK.</p>
<p dir=3D"ltr">That&#39;s not what I meant. Right now, it is easy to write =
code where side effects must be sequenced: use semicolon, comma operator or=
 logical operators. It is also easy to write code where side effects can oc=
cur in any order: combine them into a single expression not using the seque=
ncing operators. Under the proposal, the latter would be impossible to expr=
ess. </p>
<p dir=3D"ltr">&gt;&gt; It is less efficient, because certain code transfor=
mations (to reduce data dependencies, e.g.) and parallelisations are exclud=
ed.<br>
&gt;<br>
&gt; I would have thought that, in many cases, the compiler could still re-=
order under an as-if rule.</p>
<p dir=3D"ltr">Often, yes, but the more interesting cases are where an inte=
rvening function call is not available or not known. And there are cases wh=
ere the compiler would have to consider possible aliasing of data pointers =
that can be ignored under a transformed code. </p>
<p dir=3D"ltr">&gt;&gt; It is less maintainable, because one cannot reorder=
 function arguments when changing APIs, reorder subexpressions, or merge ch=
anges without having to consider all possible side effects.<br>
&gt;<br>
&gt; Yes, that=E2=80=99s the price of side effects, not evaluation order. A=
ny side effects that might happen are just as damaging now as they would be=
 with left-to-right evaluation. Because, right now, any order can happen. S=
o, any reordering right now is potentially just as damaging as any re-order=
ing under a left-to-right rule. So, unless I=E2=80=99m missing something, I=
 think this point is a red herring.</p>
<p dir=3D"ltr">Not all side effects need to be ordered. I suppose this is a=
 corollary of the first point; if there is a way to express that any side e=
ffects can occur in any order then that part of the program is more amenabl=
e to refactoring.</p>
<p dir=3D"ltr">&gt;&gt; And I should also have mentioned programmers whose =
code assumes RTL evaluation order; I don&#39;t feel any particular identifi=
cation with them, but would point out that your proposed change massively p=
rivileges your code debt over theirs.<br>
&gt;<br>
&gt;<br>
&gt; What code debt? Sorry, I=E2=80=99m just not following. How can left-to=
-right disadvantage or privilege anyone, given that, currently, there no de=
fined order whatsoever?</p>
<p dir=3D"ltr">Respondents have described code that silently depends on LTR=
.. Given that some implementations have used RTL, there must be some legacy =
code in existence that assumes RTL. This would break under compulsory LTR, =
whereas it can continue to work under the current dispensation, either by t=
urning down optimization or via compatibility flags. </p>

<p></p>

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

--001a113ea6c27889e6052d373029--

.

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

On 4 Mar 2016 12:29, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> People have wildly different expectations, and that largely depends on
what they start programming with. And people who have never programmed
before usually have expectations that have no connection to the technical
reality. Those who grow up speaking and writing a left-to-right language
have it ingrained in their head that all sequences of things are
let-to-right as that is the direction they read and write in. In math class
they are given the exercise f(g(x) + h(x)) and how do they intuitively
solve it? They calculate a=g(x) first, then b=h(x), then c=a+b, then f(c).
Try getting rid of this intuition after applying it for several years
during the phase of your live where the brain solidifies such patterns.
They expect the programming language to work the same because programming
and math are very closely related, and all the modern languages actually
*do* fulfill this expectation.
>

What do they do when given f(x) + g(x) * h(x)?

Mathematical formulae - which programming language expressions model - do
not have side effects, so intermediate results can be computed in any
order. Any reasonably competent student will exploit this to perform CSE
and other rewriting tricks to simplify the computation, so the similar
tricks the compiler performs should be intimately familiar.

Then, too, when they're learning fundamentals of programming languages,
they will discover that the order in which term rewriting rules are applied
can affect, if not the result, then certainly how long it takes to reach
the result and even whether the result is reached at all (for weakly
normalizing terms). So I don't believe that programming novices expect any
particular evaluation order, irrespective of what human languages they
speak.

--
You received this message because you are 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/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 4 Mar 2016 12:29, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; People have wildly different expectations, and that largely depends on=
 what they start programming with. And people who have never programmed bef=
ore usually have expectations that have no connection to the technical real=
ity. Those who grow up speaking and writing a left-to-right language have i=
t ingrained in their head that all sequences of things are let-to-right as =
that is the direction they read and write in. In math class they are given =
the exercise f(g(x) + h(x)) and how do they intuitively solve it? They calc=
ulate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, then f(c). Try getting r=
id of this intuition after applying it for several years during the phase o=
f your live where the brain solidifies such patterns. They expect the progr=
amming language to work the same because programming and math are very clos=
ely related, and all the modern languages actually *do* fulfill this expect=
ation.<br>
&gt;</p>
<p dir=3D"ltr">What do they do when given f(x) + g(x) * h(x)?</p>
<p dir=3D"ltr">Mathematical formulae - which programming language expressio=
ns model - do not have side effects, so intermediate results can be compute=
d in any order. Any reasonably competent student will exploit this to perfo=
rm CSE and other rewriting tricks to simplify the computation, so the simil=
ar tricks the compiler performs should be intimately familiar. </p>
<p dir=3D"ltr">Then, too, when they&#39;re learning fundamentals of program=
ming languages, they will discover that the order in which term rewriting r=
ules are applied can affect, if not the result, then certainly how long it =
takes to reach the result and even whether the result is reached at all (fo=
r weakly normalizing terms). So I don&#39;t believe that programming novice=
s expect any particular evaluation order, irrespective of what human langua=
ges they speak. </p>

<p></p>

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

--001a1140f750cef8f0052d37e98d--

.

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

@Patrice Code does not get broken because of _expectations_ about order of
evaluation.  Code gets written that has _unnoticed_ dependency on order of
evaluation, but happens to work because the compiler evaluates things in a
particular order.  Until one day that order changes.

@Edward It doesn't matter whether compulsory order breaks existing code.
We didn't object when turning on optimization broke our code.  What matters
is that compulsory order keeps code from being broken. When new code is
written requiring some evaluation order, it will either always work or
always fail.  When old code depends on evaluation order and works under
compulsory order, it will always continue to work.  Neither will silently
lurk with unspecified behavior waiting to break in the future.  If we had
had compulsory order, we would not have had the error.

It's clearly impossible to convince the unorderists that they're wrong.
But it's important to keep the issue alive so that people know that the
other side exists and isn't going to be silent.

On Fri, Mar 4, 2016 at 7:04 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

>
> On 4 Mar 2016 12:29, "Miro Knejp" <miro.knejp@gmail.com> wrote:
> >
> > People have wildly different expectations, and that largely depends on
> what they start programming with. And people who have never programmed
> before usually have expectations that have no connection to the technical
> reality. Those who grow up speaking and writing a left-to-right language
> have it ingrained in their head that all sequences of things are
> let-to-right as that is the direction they read and write in. In math class
> they are given the exercise f(g(x) + h(x)) and how do they intuitively
> solve it? They calculate a=g(x) first, then b=h(x), then c=a+b, then f(c).
> Try getting rid of this intuition after applying it for several years
> during the phase of your live where the brain solidifies such patterns.
> They expect the programming language to work the same because programming
> and math are very closely related, and all the modern languages actually
> *do* fulfill this expectation.
> >
>
> What do they do when given f(x) + g(x) * h(x)?
>
> Mathematical formulae - which programming language expressions model - do
> not have side effects, so intermediate results can be computed in any
> order. Any reasonably competent student will exploit this to perform CSE
> and other rewriting tricks to simplify the computation, so the similar
> tricks the compiler performs should be intimately familiar.
>
> Then, too, when they're learning fundamentals of programming languages,
> they will discover that the order in which term rewriting rules are applied
> can affect, if not the result, then certainly how long it takes to reach
> the result and even whether the result is reached at all (for weakly
> normalizing terms). So I don't believe that programming novices expect any
> particular evaluation order, irrespective of what human languages they
> speak.
>
> --
> You received this message because you are 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/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%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/CAHSYqdaL%2BHznUzDeErrhQMW7oPQ-H-zn92xC0vfffcuisVHh8g%40mail.gmail.com.

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

<div dir=3D"ltr">@Patrice Code does not get broken because of _expectations=
_ about order of evaluation.=C2=A0 Code gets written that has _unnoticed_ d=
ependency on order of evaluation, but happens to work because the compiler =
evaluates things in a particular order.=C2=A0 Until one day that order chan=
ges.<br><br>@Edward It doesn&#39;t matter whether compulsory order breaks e=
xisting code.=C2=A0 We didn&#39;t object when turning on optimization broke=
 our code.=C2=A0 What matters is that compulsory order keeps code from bein=
g broken. When new code is written requiring some evaluation order, it will=
 either always work or always fail.=C2=A0 When old code depends on evaluati=
on order and works under compulsory order, it will always continue to work.=
=C2=A0 Neither will silently lurk with unspecified behavior waiting to brea=
k in the future.=C2=A0 If we had had compulsory order, we would not have ha=
d the error.<br><br>It&#39;s clearly impossible to convince the unorderists=
 that they&#39;re wrong.=C2=A0 But it&#39;s important to keep the issue ali=
ve so that people know that the other side exists and isn&#39;t going to be=
 silent.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Fri, Mar 4, 2016 at 7:04 AM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</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"><br>
On 4 Mar 2016 12:29, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; People have wildly different expectations, and that largely depends on=
 what they start programming with. And people who have never programmed bef=
ore usually have expectations that have no connection to the technical real=
ity. Those who grow up speaking and writing a left-to-right language have i=
t ingrained in their head that all sequences of things are let-to-right as =
that is the direction they read and write in. In math class they are given =
the exercise f(g(x) + h(x)) and how do they intuitively solve it? They calc=
ulate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, then f(c). Try getting r=
id of this intuition after applying it for several years during the phase o=
f your live where the brain solidifies such patterns. They expect the progr=
amming language to work the same because programming and math are very clos=
ely related, and all the modern languages actually *do* fulfill this expect=
ation.<br>
&gt;</p>
</span><p dir=3D"ltr">What do they do when given f(x) + g(x) * h(x)?</p>
<p dir=3D"ltr">Mathematical formulae - which programming language expressio=
ns model - do not have side effects, so intermediate results can be compute=
d in any order. Any reasonably competent student will exploit this to perfo=
rm CSE and other rewriting tricks to simplify the computation, so the simil=
ar tricks the compiler performs should be intimately familiar. </p>
<p dir=3D"ltr">Then, too, when they&#39;re learning fundamentals of program=
ming languages, they will discover that the order in which term rewriting r=
ules are applied can affect, if not the result, then certainly how long it =
takes to reach the result and even whether the result is reached at all (fo=
r weakly normalizing terms). So I don&#39;t believe that programming novice=
s expect any particular evaluation order, irrespective of what human langua=
ges they speak. </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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2B=
RsT8n1cdHYR6u0Rg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaL%2BHznUzDeErrhQMW7oPQ-H-zn92=
xC0vfffcuisVHh8g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaL%2BHzn=
UzDeErrhQMW7oPQ-H-zn92xC0vfffcuisVHh8g%40mail.gmail.com</a>.<br />

--001a11440176bc83e1052d3b15bb--

.

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

@Hyman The moment you attack a person rather than the argument they are
making, you've already lost, because you are treating the other person as
if they are less than you are, as if they don't have reasons and rationals
for their opinions and only you are the true arbiter of reality. I'd expect
more on this list, and having heard your prior arguments.

Furthermore, the fact there is a lot of back and forth on this clearly
indicates there is at the very least a perceived need to preserve the
expressiveness we currently have; are you okay with adding a new construct
the language to demand unspecified order, since you seem so intent on
taking it out in the first place?

On Fri, Mar 4, 2016 at 10:50 AM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> @Patrice Code does not get broken because of _expectations_ about order of
> evaluation.  Code gets written that has _unnoticed_ dependency on order of
> evaluation, but happens to work because the compiler evaluates things in a
> particular order.  Until one day that order changes.
>
> @Edward It doesn't matter whether compulsory order breaks existing code.
> We didn't object when turning on optimization broke our code.  What matters
> is that compulsory order keeps code from being broken. When new code is
> written requiring some evaluation order, it will either always work or
> always fail.  When old code depends on evaluation order and works under
> compulsory order, it will always continue to work.  Neither will silently
> lurk with unspecified behavior waiting to break in the future.  If we had
> had compulsory order, we would not have had the error.
>
> It's clearly impossible to convince the unorderists that they're wrong.
> But it's important to keep the issue alive so that people know that the
> other side exists and isn't going to be silent.
>
> On Fri, Mar 4, 2016 at 7:04 AM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>>
>> On 4 Mar 2016 12:29, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>> >
>> > People have wildly different expectations, and that largely depends on
>> what they start programming with. And people who have never programmed
>> before usually have expectations that have no connection to the technical
>> reality. Those who grow up speaking and writing a left-to-right language
>> have it ingrained in their head that all sequences of things are
>> let-to-right as that is the direction they read and write in. In math class
>> they are given the exercise f(g(x) + h(x)) and how do they intuitively
>> solve it? They calculate a=g(x) first, then b=h(x), then c=a+b, then f(c).
>> Try getting rid of this intuition after applying it for several years
>> during the phase of your live where the brain solidifies such patterns.
>> They expect the programming language to work the same because programming
>> and math are very closely related, and all the modern languages actually
>> *do* fulfill this expectation.
>> >
>>
>> What do they do when given f(x) + g(x) * h(x)?
>>
>> Mathematical formulae - which programming language expressions model - do
>> not have side effects, so intermediate results can be computed in any
>> order. Any reasonably competent student will exploit this to perform CSE
>> and other rewriting tricks to simplify the computation, so the similar
>> tricks the compiler performs should be intimately familiar.
>>
>> Then, too, when they're learning fundamentals of programming languages,
>> they will discover that the order in which term rewriting rules are applied
>> can affect, if not the result, then certainly how long it takes to reach
>> the result and even whether the result is reached at all (for weakly
>> normalizing terms). So I don't believe that programming novices expect any
>> particular evaluation order, irrespective of what human languages they
>> speak.
>>
>> --
>> You received this message because you are 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/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%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/CAHSYqdaL%2BHznUzDeErrhQMW7oPQ-H-zn92xC0vfffcuisVHh8g%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaL%2BHznUzDeErrhQMW7oPQ-H-zn92xC0vfffcuisVHh8g%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/CAMD6iD9WohXuWE9RpSejb3FOmnp6FMxJhLwt5%3D1y-0ZPbOa5Kg%40mail.gmail.com.

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

<div dir=3D"ltr">@Hyman The moment you attack a person rather than the argu=
ment they are making, you&#39;ve already lost, because you are treating the=
 other person as if they are less than you are, as if they don&#39;t have r=
easons and rationals for their opinions and only you are the true arbiter o=
f reality. I&#39;d expect more on this list, and having heard your prior ar=
guments.<div><br></div><div>Furthermore, the fact there is a lot of back an=
d forth on this clearly indicates there is at the very least a perceived ne=
ed to preserve the expressiveness we currently have; are you okay with addi=
ng a new construct the language to demand unspecified order, since you seem=
 so intent on taking it out in the first place?</div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Fri, Mar 4, 2016 at 10:50 AM, =
Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"mailto:hyman.rosen@gmail.com" =
target=3D"_blank">hyman.rosen@gmail.com</a>&gt;</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">@Patrice Code does not get broken bec=
ause of _expectations_ about order of evaluation.=C2=A0 Code gets written t=
hat has _unnoticed_ dependency on order of evaluation, but happens to work =
because the compiler evaluates things in a particular order.=C2=A0 Until on=
e day that order changes.<br><br>@Edward It doesn&#39;t matter whether comp=
ulsory order breaks existing code.=C2=A0 We didn&#39;t object when turning =
on optimization broke our code.=C2=A0 What matters is that compulsory order=
 keeps code from being broken. When new code is written requiring some eval=
uation order, it will either always work or always fail.=C2=A0 When old cod=
e depends on evaluation order and works under compulsory order, it will alw=
ays continue to work.=C2=A0 Neither will silently lurk with unspecified beh=
avior waiting to break in the future.=C2=A0 If we had had compulsory order,=
 we would not have had the error.<br><br>It&#39;s clearly impossible to con=
vince the unorderists that they&#39;re wrong.=C2=A0 But it&#39;s important =
to keep the issue alive so that people know that the other side exists and =
isn&#39;t going to be silent.</div><div><div class=3D"h5"><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Fri, Mar 4, 2016 at 7:04 AM, &#=
39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"=
ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-=
proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span><p dir=3D"ltr"><br>
On 4 Mar 2016 12:29, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; People have wildly different expectations, and that largely depends on=
 what they start programming with. And people who have never programmed bef=
ore usually have expectations that have no connection to the technical real=
ity. Those who grow up speaking and writing a left-to-right language have i=
t ingrained in their head that all sequences of things are let-to-right as =
that is the direction they read and write in. In math class they are given =
the exercise f(g(x) + h(x)) and how do they intuitively solve it? They calc=
ulate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, then f(c). Try getting r=
id of this intuition after applying it for several years during the phase o=
f your live where the brain solidifies such patterns. They expect the progr=
amming language to work the same because programming and math are very clos=
ely related, and all the modern languages actually *do* fulfill this expect=
ation.<br>
&gt;</p>
</span><p dir=3D"ltr">What do they do when given f(x) + g(x) * h(x)?</p>
<p dir=3D"ltr">Mathematical formulae - which programming language expressio=
ns model - do not have side effects, so intermediate results can be compute=
d in any order. Any reasonably competent student will exploit this to perfo=
rm CSE and other rewriting tricks to simplify the computation, so the simil=
ar tricks the compiler performs should be intimately familiar. </p>
<p dir=3D"ltr">Then, too, when they&#39;re learning fundamentals of program=
ming languages, they will discover that the order in which term rewriting r=
ules are applied can affect, if not the result, then certainly how long it =
takes to reach the result and even whether the result is reached at all (fo=
r weakly normalizing terms). So I don&#39;t believe that programming novice=
s expect any particular evaluation order, irrespective of what human langua=
ges they speak. </p><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2B=
RsT8n1cdHYR6u0Rg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAHSYqdaL%2BHznUzDeErrhQMW7oPQ-H-zn92=
xC0vfffcuisVHh8g%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdaL%2BHznUzDeErrhQMW7oPQ-H-zn92xC0vfffcuisVHh8g%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9WohXuWE9RpSejb3FOmnp6FMxJhLwt=
5%3D1y-0ZPbOa5Kg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9WohXuWE=
9RpSejb3FOmnp6FMxJhLwt5%3D1y-0ZPbOa5Kg%40mail.gmail.com</a>.<br />

--001a11402e8849d712052d3cb1a9--

.

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

On Fri, Mar 4, 2016 at 12:46 PM, Ren Industries <renindustries@gmail.com>
wrote:

> @Hyman The moment you attack a person rather than the argument they are
> making, you've already lost, because you are treating the other person as
> if they are less than you are, as if they don't have reasons and rationals
> for their opinions and only you are the true arbiter of reality. I'd expect
> more on this list, and having heard your prior arguments.
>
> Lol. Everyone becomes Dr. Phil when it comes to doling out generous
dollops of advice. _This_ kind of unsolicited psycho-analysis has no place
in this list either.

That aside, I believe Ed Catmur was presented with a real world example
where turning on a optimization caused the compiler to mess around with the
order of evaluation causing what worked in the past to silently break. If
his answer is "Why did you code write like that?", this thread will never
get anywhere.

--
You received this message because you are 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/CALEPxfuuih2BLV-jnv_NcgURGxJ2VF-XHBB6-6T60gdO7VGpGA%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Mar 4, 2016 at 12:46 PM, Ren Industries <span dir=3D"ltr">&lt;<=
a href=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@g=
mail.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">@Hyman The moment you attack a person rather than the argument the=
y are making, you&#39;ve already lost, because you are treating the other p=
erson as if they are less than you are, as if they don&#39;t have reasons a=
nd rationals for their opinions and only you are the true arbiter of realit=
y. I&#39;d expect more on this list, and having heard your prior arguments.=
<div><br></div></div></blockquote><div>Lol. Everyone becomes Dr. Phil when =
it comes to doling out generous dollops of advice. _This_ kind of unsolicit=
ed psycho-analysis has no place in this list either.<br><br>That aside, I b=
elieve Ed Catmur was presented with a real world example where turning on a=
 optimization caused the compiler to mess around with the order of evaluati=
on causing what worked in the past to silently break. If his answer is &quo=
t;Why did you code write like that?&quot;, this thread will never get anywh=
ere.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxfuuih2BLV-jnv_NcgURGxJ2VF-XHBB6=
-6T60gdO7VGpGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfuuih2BLV-j=
nv_NcgURGxJ2VF-XHBB6-6T60gdO7VGpGA%40mail.gmail.com</a>.<br />

--001a11c3735caaa4c2052d3cd993--

.

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

If I may: =C2=ABCode does not get broken because of _expectations_ about or=
der
of evaluation.  Code gets written that has _unnoticed_ dependency on order
of evaluation, but happens to work because the compiler evaluates things in
a particular order.  Until one day that order changes=C2=BB sounds more lik=
e a
plea better code reviews, or for compilers that change evaluation order
from time to time in order to ease detection of subtle bugs :) (that was
tongue-in-cheek, of course).

I understand your preoccupation with this issue, but encouraging people to
depend on a specific ordering for f() and g() in h(f(), g()) (not
necessarily in all cases, mind you) instead of encouraging people to avoid
inserting dependencies on side-effects between f() and g() does not seem
like a fix to me. Similarly, defining the ordering of beasts such as f(i++,
i++) does not strike me as something better than encouraging people not to
do so.

An aside: with respect to ordering bugs, would not static analysis tools
help in figuring them out? There are GSL sections on this topic, ES.43 and
ES.44 (direct links :
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.m=
d#Res-order
and
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.m=
d#Res-order-fct
) which suggests that tooling could help fetter out at least some of them.

Cheers!



2016-03-04 10:50 GMT-05:00 Hyman Rosen <hyman.rosen@gmail.com>:

> @Patrice Code does not get broken because of _expectations_ about order o=
f
> evaluation.  Code gets written that has _unnoticed_ dependency on order o=
f
> evaluation, but happens to work because the compiler evaluates things in =
a
> particular order.  Until one day that order changes.
>
> @Edward It doesn't matter whether compulsory order breaks existing code.
> We didn't object when turning on optimization broke our code.  What matte=
rs
> is that compulsory order keeps code from being broken. When new code is
> written requiring some evaluation order, it will either always work or
> always fail.  When old code depends on evaluation order and works under
> compulsory order, it will always continue to work.  Neither will silently
> lurk with unspecified behavior waiting to break in the future.  If we had
> had compulsory order, we would not have had the error.
>
> It's clearly impossible to convince the unorderists that they're wrong.
> But it's important to keep the issue alive so that people know that the
> other side exists and isn't going to be silent.
>
> On Fri, Mar 4, 2016 at 7:04 AM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>>
>> On 4 Mar 2016 12:29, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>> >
>> > People have wildly different expectations, and that largely depends on
>> what they start programming with. And people who have never programmed
>> before usually have expectations that have no connection to the technica=
l
>> reality. Those who grow up speaking and writing a left-to-right language
>> have it ingrained in their head that all sequences of things are
>> let-to-right as that is the direction they read and write in. In math cl=
ass
>> they are given the exercise f(g(x) + h(x)) and how do they intuitively
>> solve it? They calculate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, th=
en f(c).
>> Try getting rid of this intuition after applying it for several years
>> during the phase of your live where the brain solidifies such patterns.
>> They expect the programming language to work the same because programmin=
g
>> and math are very closely related, and all the modern languages actually
>> *do* fulfill this expectation.
>> >
>>
>> What do they do when given f(x) + g(x) * h(x)?
>>
>> Mathematical formulae - which programming language expressions model - d=
o
>> not have side effects, so intermediate results can be computed in any
>> order. Any reasonably competent student will exploit this to perform CSE
>> and other rewriting tricks to simplify the computation, so the similar
>> tricks the compiler performs should be intimately familiar.
>>
>> Then, too, when they're learning fundamentals of programming languages,
>> they will discover that the order in which term rewriting rules are appl=
ied
>> can affect, if not the result, then certainly how long it takes to reach
>> the result and even whether the result is reached at all (for weakly
>> normalizing terms). So I don't believe that programming novices expect a=
ny
>> particular evaluation order, irrespective of what human languages they
>> speak.
>>
>> --
>> 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/CAJnLdObaUb=
h2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObaU=
bh2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%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/CAHSYqdaL%2B=
HznUzDeErrhQMW7oPQ-H-zn92xC0vfffcuisVHh8g%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaL%2=
BHznUzDeErrhQMW7oPQ-H-zn92xC0vfffcuisVHh8g%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/CAKiZDp02R-h6VNRsaHFu2g25fLHBGGMoQcfFJ2O%3DGJOVN=
jMS6Q%40mail.gmail.com.

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

<div dir=3D"ltr"><div>If I may: =C2=ABCode does not get broken because of _=
expectations_ about order of=20
evaluation.=C2=A0 Code gets written that has _unnoticed_ dependency on orde=
r=20
of evaluation, but happens to work because the compiler evaluates things
 in a particular order.=C2=A0 Until one day that order changes=C2=BB sounds=
 more like a plea better code reviews, or for compilers that change evaluat=
ion order from time to time in order to ease detection of subtle bugs :) (t=
hat was tongue-in-cheek, of course).<br><br></div><div>I understand your pr=
eoccupation with this issue, but encouraging people to depend on a specific=
 ordering for f() and g() in h(f(), g()) (not necessarily in all cases, min=
d you) instead of encouraging people to avoid inserting dependencies on sid=
e-effects between f() and g() does not seem like a fix to me. Similarly, de=
fining the ordering of beasts such as f(i++, i++) does not strike me as som=
ething better than encouraging people not to do so.<br><br></div><div>An as=
ide: with respect to ordering bugs, would not static analysis tools help in=
 figuring them out? There are GSL sections on this topic, ES.43 and ES.44 (=
direct links : <a href=3D"https://github.com/isocpp/CppCoreGuidelines/blob/=
master/CppCoreGuidelines.md#Res-order">https://github.com/isocpp/CppCoreGui=
delines/blob/master/CppCoreGuidelines.md#Res-order</a> and <a href=3D"https=
://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res=
-order-fct">https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCore=
Guidelines.md#Res-order-fct</a> ) which suggests that tooling could help fe=
tter out at least some of them.<br><br></div><div>Cheers!<br></div><div><br=
></div><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2016-03-04 10:50 GMT-05:00 Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt;<=
/span>:<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">@Patrice Code do=
es not get broken because of _expectations_ about order of evaluation.=C2=
=A0 Code gets written that has _unnoticed_ dependency on order of evaluatio=
n, but happens to work because the compiler evaluates things in a particula=
r order.=C2=A0 Until one day that order changes.<br><br>@Edward It doesn&#3=
9;t matter whether compulsory order breaks existing code.=C2=A0 We didn&#39=
;t object when turning on optimization broke our code.=C2=A0 What matters i=
s that compulsory order keeps code from being broken. When new code is writ=
ten requiring some evaluation order, it will either always work or always f=
ail.=C2=A0 When old code depends on evaluation order and works under compul=
sory order, it will always continue to work.=C2=A0 Neither will silently lu=
rk with unspecified behavior waiting to break in the future.=C2=A0 If we ha=
d had compulsory order, we would not have had the error.<br><br>It&#39;s cl=
early impossible to convince the unorderists that they&#39;re wrong.=C2=A0 =
But it&#39;s important to keep the issue alive so that people know that the=
 other side exists and isn&#39;t going to be silent.</div><div><div class=
=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, M=
ar 4, 2016 at 7:04 AM, &#39;Edward Catmur&#39; via ISO C++ Standard - Futur=
e Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.or=
g" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span><p dir=3D"ltr"><br>
On 4 Mar 2016 12:29, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; People have wildly different expectations, and that largely depends on=
 what they start programming with. And people who have never programmed bef=
ore usually have expectations that have no connection to the technical real=
ity. Those who grow up speaking and writing a left-to-right language have i=
t ingrained in their head that all sequences of things are let-to-right as =
that is the direction they read and write in. In math class they are given =
the exercise f(g(x) + h(x)) and how do they intuitively solve it? They calc=
ulate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, then f(c). Try getting r=
id of this intuition after applying it for several years during the phase o=
f your live where the brain solidifies such patterns. They expect the progr=
amming language to work the same because programming and math are very clos=
ely related, and all the modern languages actually *do* fulfill this expect=
ation.<br>
&gt;</p>
</span><p dir=3D"ltr">What do they do when given f(x) + g(x) * h(x)?</p>
<p dir=3D"ltr">Mathematical formulae - which programming language expressio=
ns model - do not have side effects, so intermediate results can be compute=
d in any order. Any reasonably competent student will exploit this to perfo=
rm CSE and other rewriting tricks to simplify the computation, so the simil=
ar tricks the compiler performs should be intimately familiar. </p>
<p dir=3D"ltr">Then, too, when they&#39;re learning fundamentals of program=
ming languages, they will discover that the order in which term rewriting r=
ules are applied can affect, if not the result, then certainly how long it =
takes to reach the result and even whether the result is reached at all (fo=
r weakly normalizing terms). So I don&#39;t believe that programming novice=
s expect any particular evaluation order, irrespective of what human langua=
ges they speak. </p><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2B=
RsT8n1cdHYR6u0Rg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby%2BRsT8n1cdHYR6u0Rg%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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAHSYqdaL%2BHznUzDeErrhQMW7oPQ-H-zn92=
xC0vfffcuisVHh8g%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdaL%2BHznUzDeErrhQMW7oPQ-H-zn92xC0vfffcuisVHh8g%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp02R-h6VNRsaHFu2g25fLHBGGMoQcfF=
J2O%3DGJOVNjMS6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp02R-h6VN=
RsaHFu2g25fLHBGGMoQcfFJ2O%3DGJOVNjMS6Q%40mail.gmail.com</a>.<br />

--001a11457788af6ad9052d3e74eb--

.

This is a multi-part message in MIME format.
--------------080809080009070400040304
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 04.03.2016 um 13:04 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>
> On 4 Mar 2016 12:29, "Miro Knejp" <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
> >
> > People have wildly different expectations, and that largely depends
> on what they start programming with. And people who have never
> programmed before usually have expectations that have no connection to
> the technical reality. Those who grow up speaking and writing a
> left-to-right language have it ingrained in their head that all
> sequences of things are let-to-right as that is the direction they
> read and write in. In math class they are given the exercise f(g(x) +
> h(x)) and how do they intuitively solve it? They calculate a=g(x)
> first, then b=h(x), then c=a+b, then f(c). Try getting rid of this
> intuition after applying it for several years during the phase of your
> live where the brain solidifies such patterns. They expect the
> programming language to work the same because programming and math are
> very closely related, and all the modern languages actually *do*
> fulfill this expectation.
> >
>
> What do they do when given f(x) + g(x) * h(x)?
>
> Mathematical formulae - which programming language expressions model -
> do not have side effects, so intermediate results can be computed in
> any order.
>
That's not the point. It doesn't matter whether math formulas have no
side effects or that they can be evaluated in any order. What matters is
the underlying psychology of the people who do the exercise, and later
the programming course. If they're used to a certain way of solving
these problems and have trained that during a critical phase of brain
develoment, they apply it to everything. It's a pattern, and our brain
is very good at identifying and applying patterns, but horrifically bad
at abandoning existing patterns.
>
> Any reasonably competent student will exploit this to perform CSE and
> other rewriting tricks to simplify the computation, so the similar
> tricks the compiler performs should be intimately familiar.
>
They do CSE because it saves *them* work, because it saves *them* time
on exams, but a machine doesn't care about that and most class or home
exercises finish computing quickly enough that execution time doesn't
matter. I argue that most beginner programming students pay optimization
absolutely no attention and probably don't even know such a thing
exists. Those with prior experience, yes, but the majority don't until
they actually get into courses that deal with data structures,
algorithms, complexities and code transforming optimizations, but until
they receive (and understand) that knowledge they may have already
decided that C++ is a stupid language and that Java is all the awesomeness.
>
> Then, too, when they're learning fundamentals of programming
> languages, they will discover that the order in which term rewriting
> rules are applied can affect, if not the result, then certainly how
> long it takes to reach the result and even whether the result is
> reached at all (for weakly normalizing terms).
>
This kind of transformation is only dealt with in courses that actually
teach the topic of code transforming optimizations. But often theses
courses are considered advanced, and sometimes even optional. The topic
of "performance" is typically only touched on in courses dealing with
data structures and algorithmic complexity, but those exercises don't
have execution times which are saved by subexpression reordering, they
are tailored specifically to show the difference betwen a hash map and a
linked list.
>
> So I don't believe that programming novices expect any particular
> evaluation order, irrespective of what human languages they speak.
>
Don't underestimate the impact a language can have on how people think.
There is evidence pointing in the direction that native one speaks
language does influence the way of thinking and problem solving (see the
weak Sapir-Whorf hypothesis) and that it even changes how a bilingual
thinks when switching between languages.

Furthermore, when we teach people programming we tell them "the machine
executes this line, then this line, then this line, ...". Is it really
too far-fetched that they would recognize a pattern, transform it and
apply the concept to expressions as well? "the machine executes this
expression, then this expression after the comma, then this expression
after the next comma, ..."

--
You received this message because you are 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/56D9E8DC.3090509%40gmail.com.

--------------080809080009070400040304
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 04.03.2016 um 13:04 schrieb 'Edward Catmur' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby+RsT8n1cdHYR6u0Rg@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr"><br>
        On 4 Mar 2016 12:29, "Miro Knejp" &lt;<a moz-do-not-send=3D"true"
          href=3D"mailto:miro.knejp@gmail.com">miro.knejp@gmail.com</a>&gt;
        wrote:<br>
        &gt;<br>
        &gt; People have wildly different expectations, and that largely
        depends on what they start programming with. And people who have
        never programmed before usually have expectations that have no
        connection to the technical reality. Those who grow up speaking
        and writing a left-to-right language have it ingrained in their
        head that all sequences of things are let-to-right as that is
        the direction they read and write in. In math class they are
        given the exercise f(g(x) + h(x)) and how do they intuitively
        solve it? They calculate a=3Dg(x) first, then b=3Dh(x), then c=3Da+=
b,
        then f(c). Try getting rid of this intuition after applying it
        for several years during the phase of your live where the brain
        solidifies such patterns. They expect the programming language
        to work the same because programming and math are very closely
        related, and all the modern languages actually *do* fulfill this
        expectation.<br>
        &gt;</p>
      <p dir=3D"ltr">What do they do when given f(x) + g(x) * h(x)?</p>
      <p dir=3D"ltr">Mathematical formulae - which programming language
        expressions model - do not have side effects, so intermediate
        results can be computed in any order. </p>
    </blockquote>
    That's not the point. It doesn't matter whether math formulas have
    no side effects or that they can be evaluated in any order. What
    matters is the underlying psychology of the people who do the
    exercise, and later the programming course. If they're used to a
    certain way of solving these problems and have trained that during a
    critical phase of brain develoment, they apply it to everything.
    It's a pattern, and our brain is very good at identifying and
    applying patterns, but horrifically bad at abandoning existing
    patterns.<br>
    <blockquote
cite=3D"mid:CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby+RsT8n1cdHYR6u0Rg@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr">Any reasonably competent student will exploit this to
        perform CSE and other rewriting tricks to simplify the
        computation, so the similar tricks the compiler performs should
        be intimately familiar. </p>
    </blockquote>
    They do CSE because it saves *them* work, because it saves *them*
    time on exams, but a machine doesn't care about that and most class
    or home exercises finish computing quickly enough that execution
    time doesn't matter. I argue that most beginner programming students
    pay optimization absolutely no attention and probably don't even
    know such a thing exists. Those with prior experience, yes, but the
    majority don't until they actually get into courses that deal with
    data structures, algorithms, complexities and code transforming
    optimizations, but until they receive (and understand) that
    knowledge they may have already decided that C++ is a stupid
    language and that Java is all the awesomeness.<br>
    <blockquote
cite=3D"mid:CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby+RsT8n1cdHYR6u0Rg@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr">Then, too, when they're learning fundamentals of
        programming languages, they will discover that the order in
        which term rewriting rules are applied can affect, if not the
        result, then certainly how long it takes to reach the result and
        even whether the result is reached at all (for weakly
        normalizing terms).</p>
    </blockquote>
    This kind of transformation is only dealt with in courses that
    actually teach the topic of code transforming optimizations. But
    often theses courses are considered advanced, and sometimes even
    optional. The topic of "performance" is typically only touched on in
    courses dealing with data structures and algorithmic complexity, but
    those exercises don't have execution times which are saved by
    subexpression reordering, they are tailored specifically to show the
    difference betwen a hash map and a linked list.<br>
    <blockquote
cite=3D"mid:CAJnLdObaUbh2VRt7UvoZMHvhBY7ciEiby+RsT8n1cdHYR6u0Rg@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr"> So I don't believe that programming novices expect
        any particular evaluation order, irrespective of what human
        languages they speak. </p>
    </blockquote>
    Don't underestimate the impact a language can have on how people
    think. There is evidence pointing in the direction that native one
    speaks language does influence the way of thinking and problem
    solving (see the weak Sapir-Whorf hypothesis) and that it even
    changes how a bilingual thinks when switching between languages.<br>
    <br>
    Furthermore, when we teach people programming we tell them "the
    machine executes this line, then this line, then this line, ...". Is
    it really too far-fetched that they would recognize a pattern,
    transform it and apply the concept to expressions as well? "the
    machine executes this expression, then this expression after the
    comma, then this expression after the next comma, ..."<br>
  </body>
</html>

<p></p>

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

--------------080809080009070400040304--

.

Am 04.03.2016 um 20:52 schrieb Patrice Roy:
> If I may: =C2=ABCode does not get broken because of _expectations_ about=
=20
> order of evaluation.  Code gets written that has _unnoticed_=20
> dependency on order of evaluation, but happens to work because the=20
> compiler evaluates things in a particular order.  Until one day that=20
> order changes=C2=BB sounds more like a plea better code reviews, or for=
=20
> compilers that change evaluation order from time to time in order to=20
> ease detection of subtle bugs :) (that was tongue-in-cheek, of course).
I sometimes wonder whether people saying one should improve the code=20
review process think code reviews are magical beings with superhuman=20
cognitive powers from another dimension. Last time I checked even=20
reviewers were just humans who could make the same mistakes the authors=20
did, and fall into the same traps, as happened with Bjarne's book.=20
Review is no guarantee for anything.
>
> I understand your preoccupation with this issue, but encouraging=20
> people to depend on a specific ordering for f() and g() in h(f(), g())=20
> (not necessarily in all cases, mind you) instead of encouraging people=20
> to avoid inserting dependencies on side-effects between f() and g()=20
> does not seem like a fix to me. Similarly, defining the ordering of=20
> beasts such as f(i++, i++) does not strike me as something better than=20
> encouraging people not to do so.
The side effect on i in f(i++, i++) is pretty obvious and immediatelly=20
apparent. The side effects of g and h in f(g(), h()) are not, especially=20
not if you don't have the source code for g and h readily available. So=20
a reviewer has to go through the entire expression, go check every=20
single function appearing in it and decide whether it has side effect=20
dependencies or not. That is also known as a waste of time.

It's always easy to say (or put in guidelines) "don't write code like=20
that" and expect the existence of this statement to magically solve all=20
the problems. But in order to not "write code like that" a programmer=20
first has to realize that they just wrote "code like that" and then=20
remember that there is a rule for "code like that".

To me that is always the top problem I see people having with coding=20
guidelines. They often don't realize that there is a guideline applying=20
to the code they just wrote. Can't really blame them when there are=20
pages upon pages of rules they have to internalize.
>
> An aside: with respect to ordering bugs, would not static analysis=20
> tools help in figuring them out? There are GSL sections on this topic,=20
> ES.43 and ES.44 (direct links :=20
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines=
..md#Res-order=20
> and=20
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines=
..md#Res-order-fct=20
> ) which suggests that tooling could help fetter out at least some of them=
..
One can only hope. Fortunately everybody is lucky and diligent enough to=20
always have these tools at hand.

--=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/56D9EE79.30802%40gmail.com.

.

--Apple-Mail=_A869AE1F-10CD-4CE1-A91D-731E467E4C38
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> That's not what I meant. Right now, it is easy to write code where side e=
ffects must be sequenced: use semicolon, comma operator or logical operator=
s. It is also easy to write code where side effects can occur in any order:=
 combine them into a single expression not using the sequencing operators. =
Under the proposal, the latter would be impossible to express.
>=20

Sure, it=E2=80=99s easy to write code where things must be sequenced. I=E2=
=80=99m arguing that there is no need to write code where side effects can =
occur in any order. Because that is almost never wanted and because the com=
piler can optimize under an =E2=80=9Cas if=E2=80=9D rule. The problem right=
 now is that it=E2=80=99s too easy to write code where side effects can occ=
ur in any order, without having meant to actually do so.
> > What code debt? Sorry, I=E2=80=99m just not following. How can left-to-=
right disadvantage or privilege anyone, given that, currently, there no def=
ined order whatsoever?
>=20
> Respondents have described code that silently depends on LTR. Given that =
some implementations have used RTL, there must be some legacy code in exist=
ence that assumes RTL. This would break under compulsory LTR, whereas it ca=
n continue to work under the current dispensation, either by turning down o=
ptimization or via compatibility flags.
>=20

OK, I get it now, thanks! So, to paraphrase, if we mandate LTR, that can po=
tentially break existing code that currently works only because it implicit=
ly assumes an order other than LTR that is currently used by its compiler.

To be honest, I=E2=80=99m not too concerned about this. For one, it=E2=80=
=99ll be rare. Second, we=E2=80=99ve survived far worse, such as the ABI br=
eak with std::list and std::string in gcc. Third, we are perfectly entitled=
 to break code that currently works only by accident. After all, it=E2=80=
=99s been undefined all along and, if it suddenly breaks, no-one has a righ=
t to complain.

Cheers,

Michi.

--=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/CC16202A-074E-4B4C-BC16-600BE47D4F93%40canonical=
..com.

--Apple-Mail=_A869AE1F-10CD-4CE1-A91D-731E467E4C38
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">That's no=
t what I meant. Right now, it is easy to write code where side effects must=
 be sequenced: use semicolon, comma operator or logical operators. It is al=
so easy to write code where side effects can occur in any order: combine th=
em into a single expression not using the sequencing operators. Under the p=
roposal, the latter would be impossible to express. </p></div></blockquote>=
<div><br class=3D""></div>Sure, it=E2=80=99s easy to write code where thing=
s must be sequenced. I=E2=80=99m arguing that there is no need to write cod=
e where side effects can occur in any order. Because that is almost never w=
anted and because the compiler can optimize under an =E2=80=9Cas if=E2=80=
=9D rule. The problem right now is that it=E2=80=99s too easy to write code=
 where side effects can occur in any order, <i class=3D"">without having me=
ant to actually do so</i>.<br class=3D""><blockquote type=3D"cite" class=3D=
""><p dir=3D"ltr" class=3D"">&gt; What code debt? Sorry, I=E2=80=99m just n=
ot following. How can left-to-right disadvantage or privilege anyone, given=
 that, currently, there no defined order whatsoever?</p><p dir=3D"ltr" clas=
s=3D"">Respondents have described code that silently depends on LTR. Given =
that some implementations have used RTL, there must be some legacy code in =
existence that assumes RTL. This would break under compulsory LTR, whereas =
it can continue to work under the current dispensation, either by turning d=
own optimization or via compatibility flags. </p></blockquote><div><br clas=
s=3D""></div>OK, I get it now, thanks! So, to paraphrase, if we mandate LTR=
, that can potentially break existing code that currently works only becaus=
e it implicitly assumes an order other than LTR that is currently used by i=
ts compiler.</div><div><br class=3D""></div><div>To be honest, I=E2=80=99m =
not too concerned about this. For one, it=E2=80=99ll be rare. Second, we=E2=
=80=99ve survived far worse, such as the ABI break with std::list and std::=
string in gcc. Third, we are perfectly entitled to break code that currentl=
y works only by accident. After all, it=E2=80=99s been undefined all along =
and, if it suddenly breaks, no-one has a right to complain.</div><div><br c=
lass=3D""></div><div>Cheers,</div><div><br class=3D""></div><div>Michi.</di=
v></body></html>

<p></p>

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

--Apple-Mail=_A869AE1F-10CD-4CE1-A91D-731E467E4C38--

.

--Apple-Mail=_9AB9A1A4-2E18-4E95-8B1B-2D9B7C633E43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> Then, too, when they're learning fundamentals of programming languages, t=
hey will discover that the order in which term rewriting rules are applied =
can affect, if not the result, then certainly how long it takes to reach th=
e result and even whether the result is reached at all (for weakly normaliz=
ing terms). So I don't believe that programming novices expect any particul=
ar evaluation order, irrespective of what human languages they speak.
>=20
My personal experience tells my that my brain doesn=E2=80=99t work the way =
you describe. My expectations and prejudices are subconscious, and there is=
 little I can do to prevent this, other than diligently reminding myself al=
l the time that =E2=80=9Cno, even though it=E2=80=99s written left to right=
, it may happen left to right.=E2=80=9D That creates a lot of friction and =
turns something that should be simple into an uphill battle.

Many years of teaching programming with C++ also tell me that out-of-order =
evaluation is surprising and creates a lot of cognitive friction. It may no=
t be a problem for everyone and, depending on coding style, the problem may=
 never arise for some people. But I *do* know from first-hand experience th=
at it *does* create a problem for quite a lot of programmers.

Cheers,

Michi.

--=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/155BB098-F8A9-4FD9-8E90-22070D2165B0%40canonical=
..com.

--Apple-Mail=_9AB9A1A4-2E18-4E95-8B1B-2D9B7C633E43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">Then, too=
, when they're learning fundamentals of programming languages, they will di=
scover that the order in which term rewriting rules are applied can affect,=
 if not the result, then certainly how long it takes to reach the result an=
d even whether the result is reached at all (for weakly normalizing terms).=
 So I don't believe that programming novices expect any particular evaluati=
on order, irrespective of what human languages they speak. </p></div></bloc=
kquote><div>My personal experience tells my that my brain doesn=E2=80=99t w=
ork the way you describe. My expectations and prejudices are subconscious, =
and there is little I can do to prevent this, other than diligently remindi=
ng myself all the time that =E2=80=9Cno, even though it=E2=80=99s written l=
eft to right, it may happen left to right.=E2=80=9D That creates a lot of f=
riction and turns something that should be simple into an uphill battle.</d=
iv><div><br class=3D""></div><div>Many years of teaching programming with C=
++ also tell me that out-of-order evaluation is surprising and creates a lo=
t of cognitive friction. It may not be a problem for everyone and, dependin=
g on coding style, the problem may never arise for some people. But I *do* =
know from first-hand experience that it *does* create a problem for&nbsp;qu=
ite a lot of programmers.</div><div><br class=3D""></div><div>Cheers,</div>=
<div><br class=3D""></div><div>Michi.</div></div></body></html>

<p></p>

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

--Apple-Mail=_9AB9A1A4-2E18-4E95-8B1B-2D9B7C633E43--

.

--Apple-Mail=_8BB0CFE5-F417-4DE0-910D-C0B93D57B461
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> An aside: with respect to ordering bugs, would not static analysis tools =
help in figuring them out? There are GSL sections on this topic, ES.43 and =
ES.44 (direct links : https://github.com/isocpp/CppCoreGuidelines/blob/mast=
er/CppCoreGuidelines.md#Res-order <https://github.com/isocpp/CppCoreGuideli=
nes/blob/master/CppCoreGuidelines.md#Res-order> and https://github.com/isoc=
pp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-order-fct <https:=
//github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-=
order-fct> ) which suggests that tooling could help fetter out at least som=
e of them.

I don=E2=80=99t believe tools would help much. As soon as an expression con=
tains a function call into a library or some such, static analysis doesn=E2=
=80=99t know what to make of that call anymore. The tool could warn that th=
is might be a problem regardless, but we=E2=80=99d just get a lot of false =
positives that way.

Michi.

--=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/78202611-ABE5-4355-A79B-4880D321ECE7%40canonical=
..com.

--Apple-Mail=_8BB0CFE5-F417-4DE0-910D-C0B93D57B461
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; orphans: auto; text-align: star=
t; text-indent: 0px; text-transform: none; white-space: normal; widows: aut=
o; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div clas=
s=3D"">An aside: with respect to ordering bugs, would not static analysis t=
ools help in figuring them out? There are GSL sections on this topic, ES.43=
 and ES.44 (direct links :<span class=3D"Apple-converted-space">&nbsp;</spa=
n><a href=3D"https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCor=
eGuidelines.md#Res-order" class=3D"">https://github.com/isocpp/CppCoreGuide=
lines/blob/master/CppCoreGuidelines.md#Res-order</a><span class=3D"Apple-co=
nverted-space">&nbsp;</span>and<span class=3D"Apple-converted-space">&nbsp;=
</span><a href=3D"https://github.com/isocpp/CppCoreGuidelines/blob/master/C=
ppCoreGuidelines.md#Res-order-fct" class=3D"">https://github.com/isocpp/Cpp=
CoreGuidelines/blob/master/CppCoreGuidelines.md#Res-order-fct</a><span clas=
s=3D"Apple-converted-space">&nbsp;</span>) which suggests that tooling coul=
d help fetter out at least some of them.<br class=3D""></div></div></div></=
blockquote><div><br class=3D""></div>I don=E2=80=99t believe tools would he=
lp much. As soon as an expression contains a function call into a library o=
r some such, static analysis doesn=E2=80=99t know what to make of that call=
 anymore. The tool could warn that this might be a problem regardless, but =
we=E2=80=99d just get a lot of false positives that way.</div><div><br clas=
s=3D""></div><div>Michi.</div></body></html>

<p></p>

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

--Apple-Mail=_8BB0CFE5-F417-4DE0-910D-C0B93D57B461--

.

--089e01494c2256c734052d41a656
Content-Type: text/plain; charset=UTF-8

On 5 Mar 2016 04:20, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>

> The side effect on i in f(i++, i++) is pretty obvious and immediatelly
apparent. The side effects of g and h in f(g(), h()) are not, especially
not if you don't have the source code for g and h readily available. So a
reviewer has to go through the entire expression, go check every single
function appearing in it and decide whether it has side effect dependencies
or not. That is also known as a waste of time.

If the side effects of f and g are not obvious from the names of the
functions, why would it matter what order they occur in?

--
You received this message because you are 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/CAJnLdOYVbRK6oMWfYR%2B3vAXxu4%3Dnz5oN6wgXCc2%3DQMTFmQNM6A%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 04:20, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;</p>
<p dir=3D"ltr">&gt; The side effect on i in f(i++, i++) is pretty obvious a=
nd immediatelly apparent. The side effects of g and h in f(g(), h()) are no=
t, especially not if you don&#39;t have the source code for g and h readily=
 available. So a reviewer has to go through the entire expression, go check=
 every single function appearing in it and decide whether it has side effec=
t dependencies or not. That is also known as a waste of time.</p>
<p dir=3D"ltr">If the side effects of f and g are not obvious from the name=
s of the functions, why would it matter what order they occur in? </p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYVbRK6oMWfYR%2B3vAXxu4%3Dnz5oN=
6wgXCc2%3DQMTFmQNM6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYVbR=
K6oMWfYR%2B3vAXxu4%3Dnz5oN6wgXCc2%3DQMTFmQNM6A%40mail.gmail.com</a>.<br />

--089e01494c2256c734052d41a656--

.

--Apple-Mail=_084ECEA6-C9FB-412F-A349-ACFD72EE9837
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> If the side effects of f and g are not obvious from the names of the func=
tions, why would it matter what order they occur in?
>=20
Because people write poor APIs with side effects all the time. It=E2=80=99s=
 wrong, but it=E2=80=99s common.

Michi.

--=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/A53A6424-FB2E-428F-9E27-8E230E33989A%40canonical=
..com.

--Apple-Mail=_084ECEA6-C9FB-412F-A349-ACFD72EE9837
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">If the si=
de effects of f and g are not obvious from the names of the functions, why =
would it matter what order they occur in? </p></div></blockquote><div>Becau=
se people write poor APIs with side effects all the time. It=E2=80=99s wron=
g, but it=E2=80=99s common.</div><div><br class=3D""></div><div>Michi.</div=
></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/A53A6424-FB2E-428F-9E27-8E230E33989A%=
40canonical.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/A53A6424-FB2E-428F-9E27-8E230E339=
89A%40canonical.com</a>.<br />

--Apple-Mail=_084ECEA6-C9FB-412F-A349-ACFD72EE9837--

.

--047d7bdca44005ef46052d41e8c5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5 Mar 2016 07:29, "Michi Henning" <michi.henning@canonical.com> wrote:
>>
>> That's not what I meant. Right now, it is easy to write code where side
effects must be sequenced: use semicolon, comma operator or logical
operators. It is also easy to write code where side effects can occur in
any order: combine them into a single expression not using the sequencing
operators. Under the proposal, the latter would be impossible to express.
>
>
> Sure, it=E2=80=99s easy to write code where things must be sequenced. I=
=E2=80=99m arguing
that there is no need to write code where side effects can occur in any
order. Because that is almost never wanted and because the compiler can
optimize under an =E2=80=9Cas if=E2=80=9D rule. The problem right now is th=
at it=E2=80=99s too easy
to write code where side effects can occur in any order, without having
meant to actually do so.

As-if compilation only works in simple cases. In good code written to good
APIs, it is legitimate to assume that any function whose body is not
visible does not have side effects, or does not have side effects whose
order matter. There is a need to write code where side effects, if any, can
occur in any order, if that is the author's intent.

Usually there will not be any side effects! But it is important to be able
to express that even if there are, they can still occur in any order.

--=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/CAJnLdOaAP7XrbLWdqe5hOhc1x_VZcYSmZRvKxB8uTOdcd4G=
XBA%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 07:29, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s not what I meant. Right now, it is easy to write code w=
here side effects must be sequenced: use semicolon, comma operator or logic=
al operators. It is also easy to write code where side effects can occur in=
 any order: combine them into a single expression not using the sequencing =
operators. Under the proposal, the latter would be impossible to express.<b=
r>
&gt;<br>
&gt;<br>
&gt; Sure, it=E2=80=99s easy to write code where things must be sequenced. =
I=E2=80=99m arguing that there is no need to write code where side effects =
can occur in any order. Because that is almost never wanted and because the=
 compiler can optimize under an =E2=80=9Cas if=E2=80=9D rule. The problem r=
ight now is that it=E2=80=99s too easy to write code where side effects can=
 occur in any order, without having meant to actually do so.</p>
<p dir=3D"ltr">As-if compilation only works in simple cases. In good code w=
ritten to good APIs, it is legitimate to assume that any function whose bod=
y is not visible does not have side effects, or does not have side effects =
whose order matter. There is a need to write code where side effects, if an=
y, can occur in any order, if that is the author&#39;s intent. </p>
<p dir=3D"ltr">Usually there will not be any side effects! But it is import=
ant to be able to express that even if there are, they can still occur in a=
ny order. <br>
</p>

<p></p>

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

--047d7bdca44005ef46052d41e8c5--

.

--Apple-Mail=_AE8F3B02-C320-4DC2-A79D-CFE044BFDAB8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> As-if compilation only works in simple cases. In good code written to goo=
d APIs, it is legitimate to assume that any function whose body is not visi=
ble does not have side effects, or does not have side effects whose order m=
atter. There is a need to write code where side effects, if any, can occur =
in any order, if that is the author's intent.
>=20
I think this line of reasoning is in denial of reality. Many popular and im=
portant APIs are not good, are not written in good code, and have loads of =
side effects.
> Usually there will not be any side effects! But it is important to be abl=
e to express that even if there are, they can still occur in any order.
>=20
I believe the discussion has already touched on this topic previously. I do=
n=E2=80=99t recall anyone providing convincing evidence that unordered eval=
uation provides significant optimization opportunities and, if I recall cor=
rectly, no popular compiler implements such optimizations anyway. Consequen=
tly, it is not important to express that a number of things can happen in a=
ny order.

To me, that puts this line of reasoning into the red herring category.

Cheers,

Michi.

--=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/989C9D54-275D-430F-80A8-A7DB3046E431%40canonical=
..com.

--Apple-Mail=_AE8F3B02-C320-4DC2-A79D-CFE044BFDAB8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">As-if com=
pilation only works in simple cases. In good code written to good APIs, it =
is legitimate to assume that any function whose body is not visible does no=
t have side effects, or does not have side effects whose order matter. Ther=
e is a need to write code where side effects, if any, can occur in any orde=
r, if that is the author's intent.</p></div></blockquote>I think this line =
of reasoning is in denial of reality. Many popular and important APIs are n=
ot good, are not written in good code, and have loads of side effects.<br c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><p dir=3D"lt=
r" class=3D"">Usually there will not be any side effects! But it is importa=
nt to be able to express that even if there are, they can still occur in an=
y order.<br class=3D""></p></div></blockquote><div>I believe the discussion=
 has already touched on this topic previously. I don=E2=80=99t recall anyon=
e providing convincing evidence that unordered evaluation provides signific=
ant optimization opportunities and, if I recall correctly, no popular compi=
ler implements such optimizations anyway. Consequently, it is not important=
 to express that a number of things can happen in any order.</div><div><br =
class=3D""></div><div>To me, that puts this line of reasoning into the red =
herring category.</div><div><br class=3D""></div><div>Cheers,</div><div><br=
 class=3D""></div><div>Michi.</div></div></body></html>

<p></p>

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

--Apple-Mail=_AE8F3B02-C320-4DC2-A79D-CFE044BFDAB8--

.

--047d7ba982feef898d052d427121
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 4, 2016 at 3:59 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On 5 Mar 2016 07:29, "Michi Henning" <michi.henning@canonical.com> wrote:
> >>
> >> That's not what I meant. Right now, it is easy to write code where sid=
e
> effects must be sequenced: use semicolon, comma operator or logical
> operators. It is also easy to write code where side effects can occur in
> any order: combine them into a single expression not using the sequencing
> operators. Under the proposal, the latter would be impossible to express.
> >
> > Sure, it=E2=80=99s easy to write code where things must be sequenced. I=
=E2=80=99m
> arguing that there is no need to write code where side effects can occur =
in
> any order. Because that is almost never wanted and because the compiler c=
an
> optimize under an =E2=80=9Cas if=E2=80=9D rule. The problem right now is =
that it=E2=80=99s too easy
> to write code where side effects can occur in any order, without having
> meant to actually do so.
>
> As-if compilation only works in simple cases. In good code written to goo=
d
> APIs, it is legitimate to assume that any function whose body is not
> visible does not have side effects, or does not have side effects whose
> order matter. There is a need to write code where side effects, if any, c=
an
> occur in any order, if that is the author's intent.
>
Could you provide a real-world example of a piece of code where it was
important to express that the side effects could occur in any order (as
opposed to, say, the order in which they were written)?

I'm interpreting the lines of argument so far as:
"Sometimes unsequenced evaluation leads to better code because of
optimizations."
"But those optimizations don't exist!"
The counter-counter argument then branches three ways:
(A) "Yes they do."
(B) "Okay they don't, but they might in the future, so we should keep the
possibility open."
(C) "Okay they might never exist, but sometimes the programmer needs to
express unsequenced evaluation for some OTHER reason."
So I'm asking for some code that hopefully elucidates what those OTHER
reasons might be.

(As always, (A) would be the strongest argument: the anti-LTR side could
implement such an optimization and prove that it does improve code quality,
and/or, the pro-LTR side could implement an -fltr flag for GCC or Clang and
prove that it did not hurt code quality. I think adding an -fltr flag to
Clang would be a great idea, especially for any entity that spends a
significant amount of developer time dealing with this issue; but I'm not
volunteering. Speaking of which, it would be interesting to hear from one
of the Google C++ folks on the subject. Statistically, how many bugs are
actually caused by non-LTR evaluation, at a company that hires lots of
relatively "newbie" C++ programmers and writes a ton of code?)

=E2=80=93Arthur

--=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/CADvuK0JBsa1OrzXtEPK2hmnTR-uUktTHevpEtBQTOmf1%2B=
Qa2nA%40mail.gmail.com.

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

<div dir=3D"ltr">On Fri, Mar 4, 2016 at 3:59 PM, &#39;Edward Catmur&#39; vi=
a ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mail=
to:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>=
&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><p dir=3D"ltr">On 5 Mar 2016 07:29, &quot;M=
ichi Henning&quot; &lt;<a href=3D"mailto:michi.henning@canonical.com" targe=
t=3D"_blank">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s not what I meant. Right now, it is easy to write code w=
here side effects must be sequenced: use semicolon, comma operator or logic=
al operators. It is also easy to write code where side effects can occur in=
 any order: combine them into a single expression not using the sequencing =
operators. Under the proposal, the latter would be impossible to express.<b=
r>&gt;<br>
&gt; Sure, it=E2=80=99s easy to write code where things must be sequenced. =
I=E2=80=99m arguing that there is no need to write code where side effects =
can occur in any order. Because that is almost never wanted and because the=
 compiler can optimize under an =E2=80=9Cas if=E2=80=9D rule. The problem r=
ight now is that it=E2=80=99s too easy to write code where side effects can=
 occur in any order, without having meant to actually do so.</p>
<p dir=3D"ltr">As-if compilation only works in simple cases. In good code w=
ritten to good APIs, it is legitimate to assume that any function whose bod=
y is not visible does not have side effects, or does not have side effects =
whose order matter. There is a need to write code where side effects, if an=
y, can occur in any order, if that is the author&#39;s intent.</p></blockqu=
ote><div>Could you provide a real-world example of a piece of code where it=
 was important to express that the side effects could occur in any order (a=
s opposed to, say, the order in which they were written)?</div><div><br></d=
iv><div>I&#39;m interpreting the lines of argument so far as:</div><div>&qu=
ot;Sometimes unsequenced evaluation leads to better code because of optimiz=
ations.&quot;</div><div>&quot;But those optimizations don&#39;t exist!&quot=
;</div><div>The counter-counter argument then branches three ways:</div><di=
v>(A) &quot;Yes they do.&quot;</div><div>(B) &quot;Okay they don&#39;t, but=
 they might in the future, so we should keep the possibility open.&quot;</d=
iv><div>(C) &quot;Okay they might never exist, but sometimes the programmer=
 needs to express unsequenced evaluation for some OTHER reason.&quot;</div>=
<div>So I&#39;m asking for some code that hopefully elucidates what those O=
THER reasons might be.</div><div><br></div><div>(As always, (A) would be th=
e strongest argument: the anti-LTR side could implement such an optimizatio=
n and prove that it does improve code quality, and/or, the pro-LTR side cou=
ld implement an -fltr flag for GCC or Clang and prove that it did not hurt =
code quality. I think adding an -fltr flag to Clang would be a great idea, =
especially for any entity that spends a significant amount of developer tim=
e dealing with this issue; but I&#39;m not volunteering. Speaking of which,=
 it would be interesting to hear from one of the Google C++ folks on the su=
bject. Statistically, how many bugs are actually caused by non-LTR evaluati=
on, at a company that hires lots of relatively &quot;newbie&quot; C++ progr=
ammers and writes a ton of code?)</div><div><br></div><div>=E2=80=93Arthur<=
/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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JBsa1OrzXtEPK2hmnTR-uUktTHevpE=
tBQTOmf1%2BQa2nA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JBsa1Orz=
XtEPK2hmnTR-uUktTHevpEtBQTOmf1%2BQa2nA%40mail.gmail.com</a>.<br />

--047d7ba982feef898d052d427121--

.

--047d7b2e47c89bcf64052d42a576
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5 Mar 2016 08:06, "Michi Henning" <michi.henning@canonical.com> wrote:
>>
>> As-if compilation only works in simple cases. In good code written to
good APIs, it is legitimate to assume that any function whose body is not
visible does not have side effects, or does not have side effects whose
order matter. There is a need to write code where side effects, if any, can
occur in any order, if that is the author's intent.
>
> I think this line of reasoning is in denial of reality. Many popular and
important APIs are not good, are not written in good code, and have loads
of side effects.

That's not a reality I'm familiar with, so I'd appreciate your help in
figuring out how large a reality it is. The APIs I'm familiar with are, by
and large, pretty good so any potentially dangerous calls stand out like a
sore thumb.

>> Usually there will not be any side effects! But it is important to be
able to express that even if there are, they can still occur in any order.
>
> I believe the discussion has already touched on this topic previously. I
don=E2=80=99t recall anyone providing convincing evidence that unordered ev=
aluation
provides significant optimization opportunities and, if I recall correctly,
no popular compiler implements such optimizations anyway. Consequently, it
is not important to express that a number of things can happen in any order=
..
>

That's a non sequitur. Preserving the possibility of future optimizations
is valuable in and of itself, and there are other reasons to want to be
able to express an absence of ordering requirement.

--=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/CAJnLdObV7f8LMKvj4D3r6Vjh07Cvq8d2O%3DuVGX235i%2B=
da_Ga9Q%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 08:06, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; As-if compilation only works in simple cases. In good code written=
 to good APIs, it is legitimate to assume that any function whose body is n=
ot visible does not have side effects, or does not have side effects whose =
order matter. There is a need to write code where side effects, if any, can=
 occur in any order, if that is the author&#39;s intent.<br>
&gt;<br>
&gt; I think this line of reasoning is in denial of reality. Many popular a=
nd important APIs are not good, are not written in good code, and have load=
s of side effects.</p>
<p dir=3D"ltr">That&#39;s not a reality I&#39;m familiar with, so I&#39;d a=
ppreciate your help in figuring out how large a reality it is. The APIs I&#=
39;m familiar with are, by and large, pretty good so any potentially danger=
ous calls stand out like a sore thumb. </p>
<p dir=3D"ltr">&gt;&gt; Usually there will not be any side effects! But it =
is important to be able to express that even if there are, they can still o=
ccur in any order.<br>
&gt;<br>
&gt; I believe the discussion has already touched on this topic previously.=
 I don=E2=80=99t recall anyone providing convincing evidence that unordered=
 evaluation provides significant optimization opportunities and, if I recal=
l correctly, no popular compiler implements such optimizations anyway. Cons=
equently, it is not important to express that a number of things can happen=
 in any order.<br>
&gt;</p>
<p dir=3D"ltr">That&#39;s a non sequitur. Preserving the possibility of fut=
ure optimizations is valuable in and of itself, and there are other reasons=
 to want to be able to express an absence of ordering requirement. </p>

<p></p>

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

--047d7b2e47c89bcf64052d42a576--

.

--089e01227e3ca7ffea052d42dbc8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 4, 2016 at 7:52 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

>
> On 5 Mar 2016 08:06, "Michi Henning" <michi.henning@canonical.com>
> wrote:> I believe the discussion has already touched on this topic
> previously. I don=E2=80=99t recall anyone providing convincing evidence t=
hat
> unordered evaluation provides significant optimization opportunities and,
> if I recall correctly, no popular compiler implements such optimizations
> anyway. Consequently, it is not important to express that a number of
> things can happen in any order.
>
> >
>
> That's a non sequitur. Preserving the possibility of future optimizations
> is valuable in and of itself, and there are other reasons to want to be
> able to express an absence of ordering requirement.
>

How can it be a non-sequitur? If I take my snow shovel to Arizona, keep it
in my garage, should I throw it out because there just doesn't seem to be
any evidence of snow in x number of years or should I preserve it for
"future eventualities"? Makes no sense to me.

There is NO evidence that compilers are exploiting the unspecified order of
evaluation to produce blazingly fast and optimized code (unless you think
mere re-ordering of such expressions is an optimization in itself). I think
to make this discussion concrete one must present (at least a hypothetical)
example where such freedom can potentially be used by the compiler in a
reasonable way and how mandating an order can break the observable
behaviour of a program.


> --
> 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/oQUOtYX4R3o/=
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/CAJnLdObV7f8=
LMKvj4D3r6Vjh07Cvq8d2O%3DuVGX235i%2Bda_Ga9Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObV7f=
8LMKvj4D3r6Vjh07Cvq8d2O%3DuVGX235i%2Bda_Ga9Q%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/CALEPxftBndVLQ%2BNoJdFmVuJrFEw%2BNS2q2NPnuUf6aDA=
o4e9y1A%40mail.gmail.com.

--089e01227e3ca7ffea052d42dbc8
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 Fri, Mar 4, 2016 at 7:52 PM, &#39;Edward Catmur&#39; via ISO C++ Standar=
d - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@=
isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr"><br>
On 5 Mar 2016 08:06, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com" target=3D"_blank">michi.henning@canonical.com</a>&gt=
; wrote:&gt; I believe the discussion has already touched on this topic pre=
viously. I don=E2=80=99t recall anyone providing convincing evidence that u=
nordered evaluation provides significant optimization opportunities and, if=
 I recall correctly, no popular compiler implements such optimizations anyw=
ay. Consequently, it is not important to express that a number of things ca=
n happen in any order.<br></p></span><span class=3D""><p dir=3D"ltr">
&gt;</p>
</span><p dir=3D"ltr">That&#39;s a non sequitur. Preserving the possibility=
 of future optimizations is valuable in and of itself, and there are other =
reasons to want to be able to express an absence of ordering requirement.</=
p></blockquote><div><br></div><div>How can it be a non-sequitur? If I take =
my snow shovel to Arizona, keep it in my garage, should I throw it out beca=
use there just doesn&#39;t seem to be any evidence of snow in x number of y=
ears or should I preserve it for &quot;future eventualities&quot;? Makes no=
 sense to me.</div><div><br></div><div>There is NO evidence that compilers =
are exploiting the unspecified order of evaluation to produce blazingly fas=
t and optimized code (unless you think mere re-ordering of such expressions=
 is an optimization in itself). I think to make this discussion concrete on=
e must present (at least a hypothetical) example where such freedom can pot=
entially be used by the compiler in a reasonable way and how mandating an o=
rder can break the observable behaviour of a program.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><p dir=3D"ltr"> </p><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CAJnLdObV7f8LMKvj4D3r6Vjh07Cvq8d2O%3D=
uVGX235i%2Bda_Ga9Q%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAJnLdObV7f8LMKvj4D3r6Vjh07Cvq8d2O%3DuVGX235i%2Bda_Ga9Q%40mail.gma=
il.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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxftBndVLQ%2BNoJdFmVuJrFEw%2BNS2q=
2NPnuUf6aDAo4e9y1A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxftBndVL=
Q%2BNoJdFmVuJrFEw%2BNS2q2NPnuUf6aDAo4e9y1A%40mail.gmail.com</a>.<br />

--089e01227e3ca7ffea052d42dbc8--

.

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

On 5 Mar 2016 08:38, "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com> wrote:
>
> I'm interpreting the lines of argument so far as:
> "Sometimes unsequenced evaluation leads to better code because of
optimizations."
> "But those optimizations don't exist!"
> The counter-counter argument then branches three ways:
> (A) "Yes they do."
> (B) "Okay they don't, but they might in the future, so we should keep the
possibility open."
> (C) "Okay they might never exist, but sometimes the programmer needs to
express unsequenced evaluation for some OTHER reason."
> So I'm asking for some code that hopefully elucidates what those OTHER
reasons might be.

If expressing programmer intent is not sufficient, then maintainability,
for one. It is far easier to refactor an expression, change APIs, merge
changes etc. if one does not have to worry about order dependencies.

--
You received this message because you are 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/CAJnLdObOEk05_J%3Dy6bCO9YHXHLYvFJVsXmuV%2Bo%2B9fkMCjRLE%3Dg%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 08:38, &quot;Arthur O&#39;Dwyer&quot; &lt;<a href=3D"mailto:a=
rthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I&#39;m interpreting the lines of argument so far as:<br>
&gt; &quot;Sometimes unsequenced evaluation leads to better code because of=
 optimizations.&quot;<br>
&gt; &quot;But those optimizations don&#39;t exist!&quot;<br>
&gt; The counter-counter argument then branches three ways:<br>
&gt; (A) &quot;Yes they do.&quot;<br>
&gt; (B) &quot;Okay they don&#39;t, but they might in the future, so we sho=
uld keep the possibility open.&quot;<br>
&gt; (C) &quot;Okay they might never exist, but sometimes the programmer ne=
eds to express unsequenced evaluation for some OTHER reason.&quot;<br>
&gt; So I&#39;m asking for some code that hopefully elucidates what those O=
THER reasons might be.</p>
<p dir=3D"ltr">If expressing programmer intent is not sufficient, then main=
tainability, for one. It is far easier to refactor an expression, change AP=
Is, merge changes etc. if one does not have to worry about order dependenci=
es. <br>
</p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObOEk05_J%3Dy6bCO9YHXHLYvFJVsXm=
uV%2Bo%2B9fkMCjRLE%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObO=
Ek05_J%3Dy6bCO9YHXHLYvFJVsXmuV%2Bo%2B9fkMCjRLE%3Dg%40mail.gmail.com</a>.<br=
 />

--001a1140f7509576c5052d4313c2--

.

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

On 5 Mar 2016 09:07, "Dilip Ranganathan" <misc.usage@gmail.com> wrote:
>
> There is NO evidence that compilers are exploiting the unspecified order
of evaluation to produce blazingly fast and optimized code (unless you
think mere re-ordering of such expressions is an optimization in itself). I
think to make this discussion concrete one must present (at least a
hypothetical) example where such freedom can potentially be used by the
compiler in a reasonable way and how mandating an order can break the
observable behaviour of a program.
>

This was presented in a previous instance of this thread. I don't have
access to it right now, but it was from Qt and it took the form f(g(a +
this->x), this->x) where the compiler would not be able to prove that g did
not modify this->x. Under free ordering the compiler can hoist the access
to this->x out of the expression.

--
You received this message because you are 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/CAJnLdOben09Dg6nQc5uNuVRpV-Nm9Lg6OS1-rJQgC-nnGkbtfw%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 09:07, &quot;Dilip Ranganathan&quot; &lt;<a href=3D"mailto:mi=
sc.usage@gmail.com">misc.usage@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; There is NO evidence that compilers are exploiting the unspecified ord=
er of evaluation to produce blazingly fast and optimized code (unless you t=
hink mere re-ordering of such expressions is an optimization in itself). I =
think to make this discussion concrete one must present (at least a hypothe=
tical) example where such freedom can potentially be used by the compiler i=
n a reasonable way and how mandating an order can break the observable beha=
viour of a program.<br>
&gt; =C2=A0</p>
<p dir=3D"ltr">This was presented in a previous instance of this thread. I =
don&#39;t have access to it right now, but it was from Qt and it took the f=
orm f(g(a + this-&gt;x), this-&gt;x) where the compiler would not be able t=
o prove that g did not modify this-&gt;x. Under free ordering the compiler =
can hoist the access to this-&gt;x out of the expression. </p>

<p></p>

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

--001a113ed678259985052d434274--

.

This is a multi-part message in MIME format.
--------------050403040407050202000902
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 05.03.2016 um 02:36 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>
> On 5 Mar 2016 09:07, "Dilip Ranganathan" <misc.usage@gmail.com
> <mailto:misc.usage@gmail.com>> wrote:
> >
> > There is NO evidence that compilers are exploiting the unspecified
> order of evaluation to produce blazingly fast and optimized code
> (unless you think mere re-ordering of such expressions is an
> optimization in itself). I think to make this discussion concrete one
> must present (at least a hypothetical) example where such freedom can
> potentially be used by the compiler in a reasonable way and how
> mandating an order can break the observable behaviour of a program.
> >
>
> This was presented in a previous instance of this thread. I don't have
> access to it right now, but it was from Qt and it took the form f(g(a
> + this->x), this->x) where the compiler would not be able to prove
> that g did not modify this->x. Under free ordering the compiler can
> hoist the access to this->x out of the expression.
>
And without knowing what the author actually intended, regardless what
the compiler does it has a 50% chance of doing the wrong thing. If the
order is undefined it's basically russian roulette with every
compilation. If the order is defined compilers *always* do either the
right or wrong thing consistently, making it easier to spot and fix the
bug. And yeah, code reviews and whatnot. Fact is, reviewers are humans
prone to the same predispositions and faults as everyone else. If the
reviewer happens to see the same intent as the author (which is likely
written in a commit message, subconciously priming the reviewer) and it
doesn't ring a bell then congratulations, a nondeterministic bug just
slipped past code review. Hilarity ensues after a bunch of completely
ridiculous sounding bug reports.

As much as I support the notion that only good code should be written,
that's simply not the reality. Bad code will always be written either
due to incompetence or ignorance. Sometimes you can do something about
it and sometimes you just have to live with it. The harder it is for
someone to do the wrong thing by default the better.

--
You received this message because you are 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/56DA46B0.90107%40gmail.com.

--------------050403040407050202000902
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 05.03.2016 um 02:36 schrieb 'Edward Catmur' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CAJnLdOben09Dg6nQc5uNuVRpV-Nm9Lg6OS1-rJQgC-nnGkbtfw@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr"><br>
        On 5 Mar 2016 09:07, "Dilip Ranganathan" &lt;<a
          moz-do-not-send=3D"true" href=3D"mailto:misc.usage@gmail.com"><a =
class=3D"moz-txt-link-abbreviated" href=3D"mailto:misc.usage@gmail.com">mis=
c.usage@gmail.com</a></a>&gt;
        wrote:<br>
        &gt;<br>
        &gt; There is NO evidence that compilers are exploiting the
        unspecified order of evaluation to produce blazingly fast and
        optimized code (unless you think mere re-ordering of such
        expressions is an optimization in itself). I think to make this
        discussion concrete one must present (at least a hypothetical)
        example where such freedom can potentially be used by the
        compiler in a reasonable way and how mandating an order can
        break the observable behaviour of a program.<br>
        &gt; =C2=A0</p>
      <p dir=3D"ltr">This was presented in a previous instance of this
        thread. I don't have access to it right now, but it was from Qt
        and it took the form f(g(a + this-&gt;x), this-&gt;x) where the
        compiler would not be able to prove that g did not modify
        this-&gt;x. Under free ordering the compiler can hoist the
        access to this-&gt;x out of the expression.<br>
      </p>
    </blockquote>
    And without knowing what the author actually intended, regardless
    what the compiler does it has a 50% chance of doing the wrong thing.
    If the order is undefined it's basically russian roulette with every
    compilation. If the order is defined compilers *always* do either
    the right or wrong thing consistently, making it easier to spot and
    fix the bug. And yeah, code reviews and whatnot. Fact is, reviewers
    are humans prone to the same predispositions and faults as everyone
    else. If the reviewer happens to see the same intent as the author
    (which is likely written in a commit message, subconciously priming
    the reviewer) and it doesn't ring a bell then congratulations, a
    nondeterministic bug just slipped past code review. Hilarity ensues
    after a bunch of completely ridiculous sounding bug reports.<br>
    <br>
    As much as I support the notion that only good code should be
    written, that's simply not the reality. Bad code will always be
    written either due to incompetence or ignorance. Sometimes you can
    do something about it and sometimes you just have to live with it.
    The harder it is for someone to do the wrong thing by default the
    better.<br>
  </body>
</html>

<p></p>

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

--------------050403040407050202000902--

.

This is a multi-part message in MIME format.
--------------010908090406040005050103
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 05.03.2016 um 02:23 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>
> On 5 Mar 2016 08:38, "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com
> <mailto:arthur.j.odwyer@gmail.com>> wrote:
> >
> > I'm interpreting the lines of argument so far as:
> > "Sometimes unsequenced evaluation leads to better code because of
> optimizations."
> > "But those optimizations don't exist!"
> > The counter-counter argument then branches three ways:
> > (A) "Yes they do."
> > (B) "Okay they don't, but they might in the future, so we should
> keep the possibility open."
> > (C) "Okay they might never exist, but sometimes the programmer needs
> to express unsequenced evaluation for some OTHER reason."
> > So I'm asking for some code that hopefully elucidates what those
> OTHER reasons might be.
>
> If expressing programmer intent is not sufficient, then
> maintainability, for one. It is far easier to refactor an expression,
> change APIs, merge changes etc. if one does not have to worry about
> order dependencies.
>
So do you have a real world example? I have a really hard time believing
the whole "intent" argument. I have yet to encounter a scenario where it
was the deliberate intent of the author to make code unsequenced. And I
don't mean "I wrote this code and it happens to be unsequenced", I mean
the driving motivation was "I desperately *want* this code to be
unsequenced". Where does this come up? Where is it important? Who is in
need of actively writing code like it?

About the optimization argument: how exactly do you quantify
optimization opportunity that does not exist yet? How do you justify the
unknown value of potential future gains against the very hard reality of
this issue coming up over and over again *right now*?

--
You received this message because you are 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/56DA478B.1080204%40gmail.com.

--------------010908090406040005050103
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 05.03.2016 um 02:23 schrieb 'Edward Catmur' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CAJnLdObOEk05_J=3Dy6bCO9YHXHLYvFJVsXmuV+o+9fkMCjRLE=3Dg@mail.gm=
ail.com"
      type=3D"cite">
      <p dir=3D"ltr"><br>
        On 5 Mar 2016 08:38, "Arthur O'Dwyer" &lt;<a
          moz-do-not-send=3D"true" href=3D"mailto:arthur.j.odwyer@gmail.com=
"><a class=3D"moz-txt-link-abbreviated" href=3D"mailto:arthur.j.odwyer@gmai=
l.com">arthur.j.odwyer@gmail.com</a></a>&gt;
        wrote:<br>
        &gt;<br>
        &gt; I'm interpreting the lines of argument so far as:<br>
        &gt; "Sometimes unsequenced evaluation leads to better code
        because of optimizations."<br>
        &gt; "But those optimizations don't exist!"<br>
        &gt; The counter-counter argument then branches three ways:<br>
        &gt; (A) "Yes they do."<br>
        &gt; (B) "Okay they don't, but they might in the future, so we
        should keep the possibility open."<br>
        &gt; (C) "Okay they might never exist, but sometimes the
        programmer needs to express unsequenced evaluation for some
        OTHER reason."<br>
        &gt; So I'm asking for some code that hopefully elucidates what
        those OTHER reasons might be.</p>
      <p dir=3D"ltr">If expressing programmer intent is not sufficient,
        then maintainability, for one. It is far easier to refactor an
        expression, change APIs, merge changes etc. if one does not have
        to worry about order dependencies. <br>
      </p>
    </blockquote>
    So do you have a real world example? I have a really hard time
    believing the whole "intent" argument. I have yet to encounter a
    scenario where it was the deliberate intent of the author to make
    code unsequenced. And I don't mean "I wrote this code and it happens
    to be unsequenced", I mean the driving motivation was "I desperately
    *want* this code to be unsequenced". Where does this come up? Where
    is it important? Who is in need of actively writing code like it?<br>
    <br>
    About the optimization argument: how exactly do you quantify
    optimization opportunity that does not exist yet? How do you justify
    the unknown value of potential future gains against the very hard
    reality of this issue coming up over and over again *right now*?<br>
  </body>
</html>

<p></p>

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

--------------010908090406040005050103--

.

--047d7b2e47c855001a052d4451d2
Content-Type: text/plain; charset=UTF-8

On 5 Mar 2016 10:36, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> Am 05.03.2016 um 02:36 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>>
>>
>> On 5 Mar 2016 09:07, "Dilip Ranganathan" <misc.usage@gmail.com> wrote:
>> >
>> > There is NO evidence that compilers are exploiting the unspecified
order of evaluation to produce blazingly fast and optimized code (unless
you think mere re-ordering of such expressions is an optimization in
itself). I think to make this discussion concrete one must present (at
least a hypothetical) example where such freedom can potentially be used by
the compiler in a reasonable way and how mandating an order can break the
observable behaviour of a program.
>> >
>>
>> This was presented in a previous instance of this thread. I don't have
access to it right now, but it was from Qt and it took the form f(g(a +
this->x), this->x) where the compiler would not be able to prove that g did
not modify this->x. Under free ordering the compiler can hoist the access
to this->x out of the expression.
>
> And without knowing what the author actually intended, regardless what
the compiler does it has a 50% chance of doing the wrong thing. If the
order is undefined it's basically russian roulette with every compilation.
If the order is defined compilers *always* do either the right or wrong
thing consistently, making it easier to spot and fix the bug. And yeah,
code reviews and whatnot. Fact is, reviewers are humans prone to the same
predispositions and faults as everyone else. If the reviewer happens to see
the same intent as the author (which is likely written in a commit message,
subconciously priming the reviewer) and it doesn't ring a bell then
congratulations, a nondeterministic bug just slipped past code review.
Hilarity ensues after a bunch of completely ridiculous sounding bug reports.

With good code there is no Russian roulette; any ordering is acceptable,
although some may be more efficient than others. Code written to bad APIs
can still be made good enough by sequencing explicitly.

> As much as I support the notion that only good code should be written,
that's simply not the reality. Bad code will always be written either due
to incompetence or ignorance. Sometimes you can do something about it and
sometimes you just have to live with it. The harder it is for someone to do
the wrong thing by default the better.

You shouldn't have to pay for what you don't use. If you write good code,
either by conscious effort or by selecting APIs that naturally promote good
code, then you shouldn't have to pay a penalty to protect people writing
bad code from the consequences of their mistakes.

--
You received this message because you are 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/CAJnLdOZ9hh8W0M%3DiDW7O0Pw4%3DdfpfKMnJS7PyPrEZRSTaQ3QLA%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 10:36, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Am 05.03.2016 um 02:36 schrieb &#39;Edward Catmur&#39; via ISO C++ Sta=
ndard - Future Proposals:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 5 Mar 2016 09:07, &quot;Dilip Ranganathan&quot; &lt;<a href=3D"=
mailto:misc.usage@gmail.com">misc.usage@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; There is NO evidence that compilers are exploiting the unspec=
ified order of evaluation to produce blazingly fast and optimized code (unl=
ess you think mere re-ordering of such expressions is an optimization in it=
self). I think to make this discussion concrete one must present (at least =
a hypothetical) example where such freedom can potentially be used by the c=
ompiler in a reasonable way and how mandating an order can break the observ=
able behaviour of a program.<br>
&gt;&gt; &gt; =C2=A0<br>
&gt;&gt;<br>
&gt;&gt; This was presented in a previous instance of this thread. I don&#3=
9;t have access to it right now, but it was from Qt and it took the form f(=
g(a + this-&gt;x), this-&gt;x) where the compiler would not be able to prov=
e that g did not modify this-&gt;x. Under free ordering the compiler can ho=
ist the access to this-&gt;x out of the expression.<br>
&gt;<br>
&gt; And without knowing what the author actually intended, regardless what=
 the compiler does it has a 50% chance of doing the wrong thing. If the ord=
er is undefined it&#39;s basically russian roulette with every compilation.=
 If the order is defined compilers *always* do either the right or wrong th=
ing consistently, making it easier to spot and fix the bug. And yeah, code =
reviews and whatnot. Fact is, reviewers are humans prone to the same predis=
positions and faults as everyone else. If the reviewer happens to see the s=
ame intent as the author (which is likely written in a commit message, subc=
onciously priming the reviewer) and it doesn&#39;t ring a bell then congrat=
ulations, a nondeterministic bug just slipped past code review. Hilarity en=
sues after a bunch of completely ridiculous sounding bug reports.</p>
<p dir=3D"ltr">With good code there is no Russian roulette; any ordering is=
 acceptable, although some may be more efficient than others. Code written =
to bad APIs can still be made good enough by sequencing explicitly. </p>
<p dir=3D"ltr">&gt; As much as I support the notion that only good code sho=
uld be written, that&#39;s simply not the reality. Bad code will always be =
written either due to incompetence or ignorance. Sometimes you can do somet=
hing about it and sometimes you just have to live with it. The harder it is=
 for someone to do the wrong thing by default the better.</p>
<p dir=3D"ltr">You shouldn&#39;t have to pay for what you don&#39;t use. If=
 you write good code, either by conscious effort or by selecting APIs that =
naturally promote good code, then you shouldn&#39;t have to pay a penalty t=
o protect people writing bad code from the consequences of their mistakes. =
</p>

<p></p>

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

--047d7b2e47c855001a052d4451d2--

.

On 5 Mar 2016, at 11:23 , 'Edward Catmur' via ISO C++ Standard - Future Pro=
posals <std-proposals@isocpp.org> wrote:

> If expressing programmer intent is not sufficient, then maintainability, =
for one. It is far easier to refactor an expression, change APIs, merge cha=
nges etc. if one does not have to worry about order dependencies.=20

It is *far* easier if order evaluation is undefined than it is when it is w=
ell-defined?

I just can=E2=80=99t swallow that without evidence. Not because I=E2=80=99m=
 trying to give you a hard time, but because I honestly can=E2=80=99t see i=
t.

Can you provide concrete examples for these cases? I=E2=80=99m genuinely in=
terested.

Cheers,

Michi.

--=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/35DA9A42-B71E-4212-BA82-0109554FAA05%40canonical=
..com.

.

--Apple-Mail=_AC4ADF10-523B-4FBA-866B-F89D94243F92
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> This was presented in a previous instance of this thread. I don't have ac=
cess to it right now, but it was from Qt and it took the form f(g(a + this-=
>x), this->x) where the compiler would not be able to prove that g did not =
modify this->x. Under free ordering the compiler can hoist the access to th=
is->x out of the expression.
>=20

Being able to hoist this->x out of the expression strikes me as singularly =
unimpressive. That optimization is highly unlikely to make any difference w=
hatsoever in the context of making a function call. And, besides, no-one wr=
ites bad code where g() would modify this->x, right? In which case the opti=
mization is pointless because it would optimize something that no-one ever =
writes anyway, no?

Michi.

--=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/BDBC76C4-8C6F-4357-BFD9-DC0F0BF44FB4%40canonical=
..com.

--Apple-Mail=_AC4ADF10-523B-4FBA-866B-F89D94243F92
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; -webkit-line-break: after-white-space;" class=3D""><div><blockquot=
e type=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">This w=
as presented in a previous instance of this thread. I don't have access to =
it right now, but it was from Qt and it took the form f(g(a + this-&gt;x), =
this-&gt;x) where the compiler would not be able to prove that g did not mo=
dify this-&gt;x. Under free ordering the compiler can hoist the access to t=
his-&gt;x out of the expression. </p></div></blockquote><div><br class=3D""=
></div>Being able to hoist this-&gt;x out of the expression strikes me as s=
ingularly unimpressive. That optimization is highly unlikely to make any di=
fference whatsoever in the context of making a function call. And, besides,=
 no-one writes bad code where g() would modify this-&gt;x, right? In which =
case the optimization is pointless because it would optimize something that=
 no-one ever writes anyway, no?</div><div><br class=3D""></div><div>Michi.<=
/div></body></html>

<p></p>

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

--Apple-Mail=_AC4ADF10-523B-4FBA-866B-F89D94243F92--

.

This is a multi-part message in MIME format.
--------------050800050709000206000405
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 05.03.2016 um 03:52 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>
> On 5 Mar 2016 10:36, "Miro Knejp" <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
> >
> > Am 05.03.2016 um 02:36 schrieb 'Edward Catmur' via ISO C++ Standard
> - Future Proposals:
> >>
> >>
> >> On 5 Mar 2016 09:07, "Dilip Ranganathan" <misc.usage@gmail.com
> <mailto:misc.usage@gmail.com>> wrote:
> >> >
> >> > There is NO evidence that compilers are exploiting the
> unspecified order of evaluation to produce blazingly fast and
> optimized code (unless you think mere re-ordering of such expressions
> is an optimization in itself). I think to make this discussion
> concrete one must present (at least a hypothetical) example where such
> freedom can potentially be used by the compiler in a reasonable way
> and how mandating an order can break the observable behaviour of a
> program.
> >> >
> >>
> >> This was presented in a previous instance of this thread. I don't
> have access to it right now, but it was from Qt and it took the form
> f(g(a + this->x), this->x) where the compiler would not be able to
> prove that g did not modify this->x. Under free ordering the compiler
> can hoist the access to this->x out of the expression.
> >
> > And without knowing what the author actually intended, regardless
> what the compiler does it has a 50% chance of doing the wrong thing.
> If the order is undefined it's basically russian roulette with every
> compilation. If the order is defined compilers *always* do either the
> right or wrong thing consistently, making it easier to spot and fix
> the bug. And yeah, code reviews and whatnot. Fact is, reviewers are
> humans prone to the same predispositions and faults as everyone else.
> If the reviewer happens to see the same intent as the author (which is
> likely written in a commit message, subconciously priming the
> reviewer) and it doesn't ring a bell then congratulations, a
> nondeterministic bug just slipped past code review. Hilarity ensues
> after a bunch of completely ridiculous sounding bug reports.
>
> With good code there is no Russian roulette; any ordering is
> acceptable, although some may be more efficient than others. Code
> written to bad APIs can still be made good enough by sequencing
> explicitly.
>
Again this whole "good code" thing. Where is this fantasy land you're
talking about and how do I get in? In the real world not every
programmer is a perfect superhuman being that never makes mistakes.
Prople writing code make mistakes. People reviewing code make mistakes.
The degree of expertise only reduces the frequency, but it still
happens. Or are you denying that fact and you never make mistakes?
>
> > As much as I support the notion that only good code should be
> written, that's simply not the reality. Bad code will always be
> written either due to incompetence or ignorance. Sometimes you can do
> something about it and sometimes you just have to live with it. The
> harder it is for someone to do the wrong thing by default the better.
>
> You shouldn't have to pay for what you don't use. If you write good
> code, either by conscious effort or by selecting APIs that naturally
> promote good code, then you shouldn't have to pay a penalty to protect
> people writing bad code from the consequences of their mistakes.
>
There are many preconditions here. I am convinced everyone is making a
conscious effort to write good code to the best of their abilities. It
just so happens that not everybody agrees what "good" code is.
Inexperienced programmers don't see problems where experienced
programmers cringe. Someone writing only mobile applications their
entire life will have a vastly different understanding of what "good"
code is compared to someone working their entire life on video game
engines. "good" code is such a subjective notion. Code that was
considerd "good" C++ 20 years ago is frowned upon today.

How exactly does one select an API that promotes good code? How much
time do I spend researching APIs before knowing which of them promote
good code? How many lines of code do I have to write against an API
before realizing it's not promoting good code, and do I then rewrite my
application against a new API and wait for the cycle to repeat? How do I
know that in advance? For what definiton of "good"? What if there is
only one API available? If the vendor of a device gives me their API and
it doesn't promotes good code, I have no choice but to accept it because
there is no alternative and no way of making them change it.

What people *shouldn't* do or have to pay for is one thing. People also
shouldn't drive drunk. What happens in reality is very different.
Unfortunately ideologies are just that. I feel like you're enormously
oversimplifying the problem.

--
You received this message because you are 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/56DA51BD.10603%40gmail.com.

--------------050800050709000206000405
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 05.03.2016 um 03:52 schrieb 'Edward Catmur' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CAJnLdOZ9hh8W0M=3DiDW7O0Pw4=3DdfpfKMnJS7PyPrEZRSTaQ3QLA@mail.gm=
ail.com"
      type=3D"cite">
      <p dir=3D"ltr"><br>
        On 5 Mar 2016 10:36, "Miro Knejp" &lt;<a moz-do-not-send=3D"true"
          href=3D"mailto:miro.knejp@gmail.com">miro.knejp@gmail.com</a>&gt;
        wrote:<br>
        &gt;<br>
        &gt; Am 05.03.2016 um 02:36 schrieb 'Edward Catmur' via ISO C++
        Standard - Future Proposals:<br>
        &gt;&gt;<br>
        &gt;&gt;<br>
        &gt;&gt; On 5 Mar 2016 09:07, "Dilip Ranganathan" &lt;<a
          moz-do-not-send=3D"true" href=3D"mailto:misc.usage@gmail.com"><a =
class=3D"moz-txt-link-abbreviated" href=3D"mailto:misc.usage@gmail.com">mis=
c.usage@gmail.com</a></a>&gt;
        wrote:<br>
        &gt;&gt; &gt;<br>
        &gt;&gt; &gt; There is NO evidence that compilers are exploiting
        the unspecified order of evaluation to produce blazingly fast
        and optimized code (unless you think mere re-ordering of such
        expressions is an optimization in itself). I think to make this
        discussion concrete one must present (at least a hypothetical)
        example where such freedom can potentially be used by the
        compiler in a reasonable way and how mandating an order can
        break the observable behaviour of a program.<br>
        &gt;&gt; &gt; =C2=A0<br>
        &gt;&gt;<br>
        &gt;&gt; This was presented in a previous instance of this
        thread. I don't have access to it right now, but it was from Qt
        and it took the form f(g(a + this-&gt;x), this-&gt;x) where the
        compiler would not be able to prove that g did not modify
        this-&gt;x. Under free ordering the compiler can hoist the
        access to this-&gt;x out of the expression.<br>
        &gt;<br>
        &gt; And without knowing what the author actually intended,
        regardless what the compiler does it has a 50% chance of doing
        the wrong thing. If the order is undefined it's basically
        russian roulette with every compilation. If the order is defined
        compilers *always* do either the right or wrong thing
        consistently, making it easier to spot and fix the bug. And
        yeah, code reviews and whatnot. Fact is, reviewers are humans
        prone to the same predispositions and faults as everyone else.
        If the reviewer happens to see the same intent as the author
        (which is likely written in a commit message, subconciously
        priming the reviewer) and it doesn't ring a bell then
        congratulations, a nondeterministic bug just slipped past code
        review. Hilarity ensues after a bunch of completely ridiculous
        sounding bug reports.</p>
      <p dir=3D"ltr">With good code there is no Russian roulette; any
        ordering is acceptable, although some may be more efficient than
        others. Code written to bad APIs can still be made good enough
        by sequencing explicitly. </p>
    </blockquote>
    Again this whole "good code" thing. Where is this fantasy land
    you're talking about and how do I get in? In the real world not
    every programmer is a perfect superhuman being that never makes
    mistakes. Prople writing code make mistakes. People reviewing code
    make mistakes. The degree of expertise only reduces the frequency,
    but it still happens. Or are you denying that fact and you never
    make mistakes?<br>
    <blockquote
cite=3D"mid:CAJnLdOZ9hh8W0M=3DiDW7O0Pw4=3DdfpfKMnJS7PyPrEZRSTaQ3QLA@mail.gm=
ail.com"
      type=3D"cite">
      <p dir=3D"ltr">&gt; As much as I support the notion that only good
        code should be written, that's simply not the reality. Bad code
        will always be written either due to incompetence or ignorance.
        Sometimes you can do something about it and sometimes you just
        have to live with it. The harder it is for someone to do the
        wrong thing by default the better.</p>
      <p dir=3D"ltr">You shouldn't have to pay for what you don't use. If
        you write good code, either by conscious effort or by selecting
        APIs that naturally promote good code, then you shouldn't have
        to pay a penalty to protect people writing bad code from the
        consequences of their mistakes. </p>
    </blockquote>
    There are many preconditions here. I am convinced everyone is making
    a conscious effort to write good code to the best of their
    abilities. It just so happens that not everybody agrees what "good"
    code is. Inexperienced programmers don't see problems where
    experienced programmers cringe. Someone writing only mobile
    applications their entire life will have a vastly different
    understanding of what "good" code is compared to someone working
    their entire life on video game engines. "good" code is such a
    subjective notion. Code that was considerd "good" C++ 20 years ago
    is frowned upon today.<br>
    <br>
    How exactly does one select an API that promotes good code? How much
    time do I spend researching APIs before knowing which of them
    promote good code? How many lines of code do I have to write against
    an API before realizing it's not promoting good code, and do I then
    rewrite my application against a new API and wait for the cycle to
    repeat? How do I know that in advance? For what definiton of "good"?
    What if there is only one API available? If the vendor of a device
    gives me their API and it doesn't promotes good code, I have no
    choice but to accept it because there is no alternative and no way
    of making them change it.<br>
    <br>
    What people *shouldn't* do or have to pay for is one thing. People
    also shouldn't drive drunk. What happens in reality is very
    different. Unfortunately ideologies are just that. I feel like
    you're enormously oversimplifying the problem.
  </body>
</html>

<p></p>

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

--------------050800050709000206000405--

.

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

On 5 Mar 2016 10:40, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> Am 05.03.2016 um 02:23 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>>
>>
>> On 5 Mar 2016 08:38, "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com> wrote:
>> >
>> > I'm interpreting the lines of argument so far as:
>> > "Sometimes unsequenced evaluation leads to better code because of
optimizations."
>> > "But those optimizations don't exist!"
>> > The counter-counter argument then branches three ways:
>> > (A) "Yes they do."
>> > (B) "Okay they don't, but they might in the future, so we should keep
the possibility open."
>> > (C) "Okay they might never exist, but sometimes the programmer needs
to express unsequenced evaluation for some OTHER reason."
>> > So I'm asking for some code that hopefully elucidates what those OTHER
reasons might be.
>>
>> If expressing programmer intent is not sufficient, then maintainability,
for one. It is far easier to refactor an expression, change APIs, merge
changes etc. if one does not have to worry about order dependencies.
>
> So do you have a real world example? I have a really hard time believing
the whole "intent" argument. I have yet to encounter a scenario where it
was the deliberate intent of the author to make code unsequenced. And I
don't mean "I wrote this code and it happens to be unsequenced", I mean the
driving motivation was "I desperately *want* this code to be unsequenced".
Where does this come up? Where is it important? Who is in need of actively
writing code like it?

Not right now - ask me next week when I'm at a computer - but it's easy to
consider cases where you need to redesign an API to reorder parameters. If
you can assume free ordering then you can automatically fix all callers;
otherwise you need to consider every call individually.

It's not about wanting the code to be unsequenced per se, it's wanting the
code to not say any more than it needs to. When I write a shopping list, I
don't expect to buy the items in that specific order.

> About the optimization argument: how exactly do you quantify optimization
opportunity that does not exist yet? How do you justify the unknown value
of potential future gains against the very hard reality of this issue
coming up over and over again *right now*?

A sunny optimism, mostly.

--
You received this message because you are 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/CAJnLdOZeNQVtHO0v0xH4kSSwBA8A-REs7%2B0VW9YSLVnAF8PcQQ%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 10:40, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Am 05.03.2016 um 02:23 schrieb &#39;Edward Catmur&#39; via ISO C++ Sta=
ndard - Future Proposals:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 5 Mar 2016 08:38, &quot;Arthur O&#39;Dwyer&quot; &lt;<a href=3D=
"mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>&gt; wrote:=
<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I&#39;m interpreting the lines of argument so far as:<br>
&gt;&gt; &gt; &quot;Sometimes unsequenced evaluation leads to better code b=
ecause of optimizations.&quot;<br>
&gt;&gt; &gt; &quot;But those optimizations don&#39;t exist!&quot;<br>
&gt;&gt; &gt; The counter-counter argument then branches three ways:<br>
&gt;&gt; &gt; (A) &quot;Yes they do.&quot;<br>
&gt;&gt; &gt; (B) &quot;Okay they don&#39;t, but they might in the future, =
so we should keep the possibility open.&quot;<br>
&gt;&gt; &gt; (C) &quot;Okay they might never exist, but sometimes the prog=
rammer needs to express unsequenced evaluation for some OTHER reason.&quot;=
<br>
&gt;&gt; &gt; So I&#39;m asking for some code that hopefully elucidates wha=
t those OTHER reasons might be.<br>
&gt;&gt;<br>
&gt;&gt; If expressing programmer intent is not sufficient, then maintainab=
ility, for one. It is far easier to refactor an expression, change APIs, me=
rge changes etc. if one does not have to worry about order dependencies. <b=
r>
&gt;<br>
&gt; So do you have a real world example? I have a really hard time believi=
ng the whole &quot;intent&quot; argument. I have yet to encounter a scenari=
o where it was the deliberate intent of the author to make code unsequenced=
.. And I don&#39;t mean &quot;I wrote this code and it happens to be unseque=
nced&quot;, I mean the driving motivation was &quot;I desperately *want* th=
is code to be unsequenced&quot;. Where does this come up? Where is it impor=
tant? Who is in need of actively writing code like it?</p>
<p dir=3D"ltr">Not right now - ask me next week when I&#39;m at a computer =
- but it&#39;s easy to consider cases where you need to redesign an API to =
reorder parameters. If you can assume free ordering then you can automatica=
lly fix all callers; otherwise you need to consider every call individually=
.. </p>
<p dir=3D"ltr">It&#39;s not about wanting the code to be unsequenced per se=
, it&#39;s wanting the code to not say any more than it needs to. When I wr=
ite a shopping list, I don&#39;t expect to buy the items in that specific o=
rder. </p>
<p dir=3D"ltr">&gt; About the optimization argument: how exactly do you qua=
ntify optimization opportunity that does not exist yet? How do you justify =
the unknown value of potential future gains against the very hard reality o=
f this issue coming up over and over again *right now*?</p>
<p dir=3D"ltr">A sunny optimism, mostly. </p>

<p></p>

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

--001a1140f750a9dc42052d451968--

.

--047d7b2e47c8b3da16052d453649
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5 Mar 2016 10:52, "Michi Henning" <michi.henning@canonical.com> wrote:
>
> On 5 Mar 2016, at 11:23 , 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>
> > If expressing programmer intent is not sufficient, then
maintainability, for one. It is far easier to refactor an expression,
change APIs, merge changes etc. if one does not have to worry about order
dependencies.
>
> It is *far* easier if order evaluation is undefined than it is when it is
well-defined?
>
> I just can=E2=80=99t swallow that without evidence. Not because I=E2=80=
=99m trying to
give you a hard time, but because I honestly can=E2=80=99t see it.
>
> Can you provide concrete examples for these cases? I=E2=80=99m genuinely
interested.

Refactoring: e.g. rewriting an arithmetic expression to group related
terms.
API changes: see above.
Merging changes: if two edits add terms to the same expression, it's easier
to combine them if the added terms can be considered independent.

I'd love to be able to point to concrete cases in open source code, but
that's a little tricky right now. Perhaps I should try playing the victim
card to get out of it.

--=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/CAJnLdOZQVzGeRp%2BNOiJkFqjZN6EaFnQRC3FRkz3XBk6bu=
QMYfg%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 10:52, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 5 Mar 2016, at 11:23 , &#39;Edward Catmur&#39; via ISO C++ Standard=
 - Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-pro=
posals@isocpp.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; If expressing programmer intent is not sufficient, then maintaina=
bility, for one. It is far easier to refactor an expression, change APIs, m=
erge changes etc. if one does not have to worry about order dependencies.<b=
r>
&gt;<br>
&gt; It is *far* easier if order evaluation is undefined than it is when it=
 is well-defined?<br>
&gt;<br>
&gt; I just can=E2=80=99t swallow that without evidence. Not because I=E2=
=80=99m trying to give you a hard time, but because I honestly can=E2=80=99=
t see it.<br>
&gt;<br>
&gt; Can you provide concrete examples for these cases? I=E2=80=99m genuine=
ly interested.</p>
<p dir=3D"ltr">Refactoring: e.g. rewriting an arithmetic expression to grou=
p related terms. <br>
API changes: see above. <br>
Merging changes: if two edits add terms to the same expression, it&#39;s ea=
sier to combine them if the added terms can be considered independent. </p>
<p dir=3D"ltr">I&#39;d love to be able to point to concrete cases in open s=
ource code, but that&#39;s a little tricky right now. Perhaps I should try =
playing the victim card to get out of it. </p>

<p></p>

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

--047d7b2e47c8b3da16052d453649--

.

--089e01494c22f45da1052d454580
Content-Type: text/plain; charset=UTF-8

On 5 Mar 2016 11:01, "Michi Henning" <michi.henning@canonical.com> wrote:
>>
>> This was presented in a previous instance of this thread. I don't have
access to it right now, but it was from Qt and it took the form f(g(a +
this->x), this->x) where the compiler would not be able to prove that g did
not modify this->x. Under free ordering the compiler can hoist the access
to this->x out of the expression.
>
>
> Being able to hoist this->x out of the expression strikes me as
singularly unimpressive. That optimization is highly unlikely to make any
difference whatsoever in the context of making a function call.

Every little helps, and the eliminated common subexpression could be more
complicated.

> And, besides, no-one writes bad code where g() would modify this->x,
right? In which case the optimization is pointless because it would
optimize something that no-one ever writes anyway, no?

That's precisely why it's valuable; the compiler can't assume the obvious
(that g won't modify x) unless given license to do so by 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/CAJnLdOY%2Ba2KVGz6GwWxDebDy1ioZ7j8Qgsoqt9xBf8%2BK9rfYTA%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 11:01, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; This was presented in a previous instance of this thread. I don&#3=
9;t have access to it right now, but it was from Qt and it took the form f(=
g(a + this-&gt;x), this-&gt;x) where the compiler would not be able to prov=
e that g did not modify this-&gt;x. Under free ordering the compiler can ho=
ist the access to this-&gt;x out of the expression.<br>
&gt;<br>
&gt;<br>
&gt; Being able to hoist this-&gt;x out of the expression strikes me as sin=
gularly unimpressive. That optimization is highly unlikely to make any diff=
erence whatsoever in the context of making a function call. </p>
<p dir=3D"ltr">Every little helps, and the eliminated common subexpression =
could be more complicated. </p>
<p dir=3D"ltr">&gt; And, besides, no-one writes bad code where g() would mo=
dify this-&gt;x, right? In which case the optimization is pointless because=
 it would optimize something that no-one ever writes anyway, no?</p>
<p dir=3D"ltr">That&#39;s precisely why it&#39;s valuable; the compiler can=
&#39;t assume the obvious (that g won&#39;t modify x) unless given license =
to do so by the language. </p>

<p></p>

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

--089e01494c22f45da1052d454580--

.

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

On 5 Mar 2016 11:23, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> Again this whole "good code" thing. Where is this fantasy land you're
talking about and how do I get in?

It's out there, in a myriad quietly successful companies with management
who appreciate and actively promote good software engineering techniques.
You get in by applying to open positions or getting recommended.

What would be the point of promoting good code if nowhere observed it?

> In the real world not every programmer is a perfect superhuman being that
never makes mistakes. Prople writing code make mistakes. People reviewing
code make mistakes. The degree of expertise only reduces the frequency, but
it still happens. Or are you denying that fact and you never make mistakes?

We make mistakes, but we have multiple lines of defence - programmer,
reviewer, architect, compiler. Good API design and compiler warnings can
catch mistakes that the programmer and reviewer don't spot.

> There are many preconditions here. I am convinced everyone is making a
conscious effort to write good code to the best of their abilities. It just
so happens that not everybody agrees what "good" code is. Inexperienced
programmers don't see problems where experienced programmers cringe.
Someone writing only mobile applications their entire life will have a
vastly different understanding of what "good" code is compared to someone
working their entire life on video game engines. "good" code is such a
subjective notion. Code that was considerd "good" C++ 20 years ago is
frowned upon today.

So you need to keep up with best practice? I don't really see a problem
here.

> How exactly does one select an API that promotes good code? How much time
do I spend researching APIs before knowing which of them promote good code?
How many lines of code do I have to write against an API before realizing
it's not promoting good code, and do I then rewrite my application against
a new API and wait for the cycle to repeat? How do I know that in advance?
For what definiton of "good"? What if there is only one API available? If
the vendor of a device gives me their API and it doesn't promotes good
code, I have no choice but to accept it because there is no alternative and
no way of making them change it.

You can always adapt a bad API; C++ makes zero- and negative-overhead
abstractions possible.

> What people *shouldn't* do or have to pay for is one thing. People also
shouldn't drive drunk. What happens in reality is very different.
Unfortunately ideologies are just that. I feel like you're enormously
oversimplifying the problem.

If not paying for what you don't use is an ideology, it's an ideology I'm
perfectly happy to be associated with. I recognise this is a complex
problem, and complex problems rarely have simple solutions.

--
You received this message because you are 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_dTx9JvE0tjPJC8aXLcOOfZP7TfYOocFg8_S9Rg_btQ%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 Mar 2016 11:23, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Again this whole &quot;good code&quot; thing. Where is this fantasy la=
nd you&#39;re talking about and how do I get in?</p>
<p dir=3D"ltr">It&#39;s out there, in a myriad quietly successful companies=
 with management who appreciate and actively promote good software engineer=
ing techniques. You get in by applying to open positions or getting recomme=
nded. </p>
<p dir=3D"ltr">What would be the point of promoting good code if nowhere ob=
served it? </p>
<p dir=3D"ltr">&gt; In the real world not every programmer is a perfect sup=
erhuman being that never makes mistakes. Prople writing code make mistakes.=
 People reviewing code make mistakes. The degree of expertise only reduces =
the frequency, but it still happens. Or are you denying that fact and you n=
ever make mistakes?</p>
<p dir=3D"ltr">We make mistakes, but we have multiple lines of defence - pr=
ogrammer, reviewer, architect, compiler. Good API design and compiler warni=
ngs can catch mistakes that the programmer and reviewer don&#39;t spot. <br=
></p>
<p dir=3D"ltr">&gt; There are many preconditions here. I am convinced every=
one is making a conscious effort to write good code to the best of their ab=
ilities. It just so happens that not everybody agrees what &quot;good&quot;=
 code is. Inexperienced programmers don&#39;t see problems where experience=
d programmers cringe. Someone writing only mobile applications their entire=
 life will have a vastly different understanding of what &quot;good&quot; c=
ode is compared to someone working their entire life on video game engines.=
 &quot;good&quot; code is such a subjective notion. Code that was considerd=
 &quot;good&quot; C++ 20 years ago is frowned upon today.</p>
<p dir=3D"ltr">So you need to keep up with best practice? I don&#39;t reall=
y see a problem here. </p>
<p dir=3D"ltr">&gt; How exactly does one select an API that promotes good c=
ode? How much time do I spend researching APIs before knowing which of them=
 promote good code? How many lines of code do I have to write against an AP=
I before realizing it&#39;s not promoting good code, and do I then rewrite =
my application against a new API and wait for the cycle to repeat? How do I=
 know that in advance? For what definiton of &quot;good&quot;? What if ther=
e is only one API available? If the vendor of a device gives me their API a=
nd it doesn&#39;t promotes good code, I have no choice but to accept it bec=
ause there is no alternative and no way of making them change it.</p>
<p dir=3D"ltr">You can always adapt a bad API; C++ makes zero- and negative=
-overhead abstractions possible. </p>
<p dir=3D"ltr">&gt; What people *shouldn&#39;t* do or have to pay for is on=
e thing. People also shouldn&#39;t drive drunk. What happens in reality is =
very different. Unfortunately ideologies are just that. I feel like you&#39=
;re enormously oversimplifying the problem.</p>
<p dir=3D"ltr">If not paying for what you don&#39;t use is an ideology, it&=
#39;s an ideology I&#39;m perfectly happy to be associated with. I recognis=
e this is a complex problem, and complex problems rarely have simple soluti=
ons. </p>

<p></p>

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

--001a113ecbe492ff99052d45f82c--

.

This is a multi-part message in MIME format.
--------------000100090100030403020501
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 05.03.2016 um 05:50 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>
> On 5 Mar 2016 11:23, "Miro Knejp" <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
> >
> > Again this whole "good code" thing. Where is this fantasy land
> you're talking about and how do I get in?
>
> It's out there, in a myriad quietly successful companies with
> management who appreciate and actively promote good software
> engineering techniques. You get in by applying to open positions or
> getting recommended.
>
> What would be the point of promoting good code if nowhere observed it?
>
Wouldn't it be great if every company was like that...
>
> > In the real world not every programmer is a perfect superhuman being
> that never makes mistakes. Prople writing code make mistakes. People
> reviewing code make mistakes. The degree of expertise only reduces the
> frequency, but it still happens. Or are you denying that fact and you
> never make mistakes?
>
> We make mistakes, but we have multiple lines of defence - programmer,
> reviewer, architect, compiler. Good API design and compiler warnings
> can catch mistakes that the programmer and reviewer don't spot.
>
Again, it's the same problem. In order for someone to design a good API
they have to know what a "good" API is in the first place. For whatever
defintion of the word "good". If somebody was never tought what a "good"
API looks like they are going to write a bad one. I have met programmers
who genuinly thought they were writing good code because they simply
didn't know it better. Some had no idea a concept like code review even
existed because it was never applied at their work place or brought up
in their college. They weren't bad programmers per se, they simply
lacked the exposure to better practices for a variety of reasons. And
sometimes such people end up working at companies where they might write
very important and widely used APIs. And sadly there are companies who
don't employ code review or similar techniques. Now you might say "they
should find a better job" but in order for that to happen they first
have to know that better alternatives exist. If the indigenous people of
the Amazonas knew about electricity, sanitation or pizza would they
still remain secluded in the rain forest?

Let's not forget that the people visiting this forum and events like
CppCon are a tiny minority of all the C++ developers out there. The
"average" C++ developer doesn't care about concepts, ranges, template
metaprogramming or the next great language standard. They write code
that looks more like Java++ than anything else and are firmly convinced
that they write good code and are happy with it. They're not bad people,
they just don't know it better and nobody corrects them. If the reviewer
is of the same level of experience nothing is gained. People don't know
how much they don't know. The less mistakes these developers can do by
default the better for everybody.
>
> > There are many preconditions here. I am convinced everyone is making
> a conscious effort to write good code to the best of their abilities.
> It just so happens that not everybody agrees what "good" code is.
> Inexperienced programmers don't see problems where experienced
> programmers cringe. Someone writing only mobile applications their
> entire life will have a vastly different understanding of what "good"
> code is compared to someone working their entire life on video game
> engines. "good" code is such a subjective notion. Code that was
> considerd "good" C++ 20 years ago is frowned upon today.
>
> So you need to keep up with best practice? I don't really see a
> problem here.
>
Best practice in one industry may not necessarily be best practice in
another.
>
> > How exactly does one select an API that promotes good code? How much
> time do I spend researching APIs before knowing which of them promote
> good code? How many lines of code do I have to write against an API
> before realizing it's not promoting good code, and do I then rewrite
> my application against a new API and wait for the cycle to repeat? How
> do I know that in advance? For what definiton of "good"? What if there
> is only one API available? If the vendor of a device gives me their
> API and it doesn't promotes good code, I have no choice but to accept
> it because there is no alternative and no way of making them change it.
>
> You can always adapt a bad API; C++ makes zero- and negative-overhead
> abstractions possible.
>
Whether I have to write against the bad API or wrap it in a C++ version
doesn't change the fact I have to work with it at some point.
>
> > What people *shouldn't* do or have to pay for is one thing. People
> also shouldn't drive drunk. What happens in reality is very different.
> Unfortunately ideologies are just that. I feel like you're enormously
> oversimplifying the problem.
>
> If not paying for what you don't use is an ideology, it's an ideology
> I'm perfectly happy to be associated with. I recognise this is a
> complex problem, and complex problems rarely have simple solutions.
>
I don't have a problem with ideologies, it's just that ideologies and
realities are very often in conflict or even incompatible for many 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/56DA6D46.4090509%40gmail.com.

--------------000100090100030403020501
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 05.03.2016 um 05:50 schrieb 'Edward Catmur' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CAJnLdOZ_dTx9JvE0tjPJC8aXLcOOfZP7TfYOocFg8_S9Rg_btQ@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr"><br>
        On 5 Mar 2016 11:23, "Miro Knejp" &lt;<a moz-do-not-send=3D"true"
          href=3D"mailto:miro.knejp@gmail.com">miro.knejp@gmail.com</a>&gt;
        wrote:<br>
        &gt;<br>
        &gt; Again this whole "good code" thing. Where is this fantasy
        land you're talking about and how do I get in?</p>
      <p dir=3D"ltr">It's out there, in a myriad quietly successful
        companies with management who appreciate and actively promote
        good software engineering techniques. You get in by applying to
        open positions or getting recommended. </p>
      <p dir=3D"ltr">What would be the point of promoting good code if
        nowhere observed it? </p>
    </blockquote>
    Wouldn't it be great if every company was like that...<br>
    <blockquote
cite=3D"mid:CAJnLdOZ_dTx9JvE0tjPJC8aXLcOOfZP7TfYOocFg8_S9Rg_btQ@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr">&gt; In the real world not every programmer is a
        perfect superhuman being that never makes mistakes. Prople
        writing code make mistakes. People reviewing code make mistakes.
        The degree of expertise only reduces the frequency, but it still
        happens. Or are you denying that fact and you never make
        mistakes?</p>
      <p dir=3D"ltr">We make mistakes, but we have multiple lines of
        defence - programmer, reviewer, architect, compiler. Good API
        design and compiler warnings can catch mistakes that the
        programmer and reviewer don't spot. <br>
      </p>
    </blockquote>
    Again, it's the same problem. In order for someone to design a good
    API they have to know what a "good" API is in the first place. For
    whatever defintion of the word "good". If somebody was never tought
    what a "good" API looks like they are going to write a bad one. I
    have met programmers who genuinly thought they were writing good
    code because they simply didn't know it better. Some had no idea a
    concept like code review even existed because it was never applied
    at their work place or brought up in their college. They weren't bad
    programmers per se, they simply lacked the exposure to better
    practices for a variety of reasons. And sometimes such people end up
    working at companies where they might write very important and
    widely used APIs. And sadly there are companies who don't employ
    code review or similar techniques. Now you might say "they should
    find a better job" but in order for that to happen they first have
    to know that better alternatives exist. If the indigenous people of
    the Amazonas knew about electricity, sanitation or pizza would they
    still remain secluded in the rain forest?<br>
    <br>
    Let's not forget that the people visiting this forum and events like
    CppCon are a tiny minority of all the C++ developers out there. The
    "average" C++ developer doesn't care about concepts, ranges,
    template metaprogramming or the next great language standard. They
    write code that looks more like Java++ than anything else and are
    firmly convinced that they write good code and are happy with it.
    They're not bad people, they just don't know it better and nobody
    corrects them. If the reviewer is of the same level of experience
    nothing is gained. People don't know how much they don't know. The
    less mistakes these developers can do by default the better for
    everybody.<br>
    <blockquote
cite=3D"mid:CAJnLdOZ_dTx9JvE0tjPJC8aXLcOOfZP7TfYOocFg8_S9Rg_btQ@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr">&gt; There are many preconditions here. I am
        convinced everyone is making a conscious effort to write good
        code to the best of their abilities. It just so happens that not
        everybody agrees what "good" code is. Inexperienced programmers
        don't see problems where experienced programmers cringe. Someone
        writing only mobile applications their entire life will have a
        vastly different understanding of what "good" code is compared
        to someone working their entire life on video game engines.
        "good" code is such a subjective notion. Code that was considerd
        "good" C++ 20 years ago is frowned upon today.</p>
      <p dir=3D"ltr">So you need to keep up with best practice? I don't
        really see a problem here. </p>
    </blockquote>
    Best practice in one industry may not necessarily be best practice
    in another.<br>
    <blockquote
cite=3D"mid:CAJnLdOZ_dTx9JvE0tjPJC8aXLcOOfZP7TfYOocFg8_S9Rg_btQ@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr">&gt; How exactly does one select an API that promotes
        good code? How much time do I spend researching APIs before
        knowing which of them promote good code? How many lines of code
        do I have to write against an API before realizing it's not
        promoting good code, and do I then rewrite my application
        against a new API and wait for the cycle to repeat? How do I
        know that in advance? For what definiton of "good"? What if
        there is only one API available? If the vendor of a device gives
        me their API and it doesn't promotes good code, I have no choice
        but to accept it because there is no alternative and no way of
        making them change it.</p>
      <p dir=3D"ltr">You can always adapt a bad API; C++ makes zero- and
        negative-overhead abstractions possible. </p>
    </blockquote>
    Whether I have to write against the bad API or wrap it in a C++
    version doesn't change the fact I have to work with it at some
    point.<br>
    <blockquote
cite=3D"mid:CAJnLdOZ_dTx9JvE0tjPJC8aXLcOOfZP7TfYOocFg8_S9Rg_btQ@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr">&gt; What people *shouldn't* do or have to pay for is
        one thing. People also shouldn't drive drunk. What happens in
        reality is very different. Unfortunately ideologies are just
        that. I feel like you're enormously oversimplifying the problem.</p=
>
      <p dir=3D"ltr">If not paying for what you don't use is an ideology,
        it's an ideology I'm perfectly happy to be associated with. I
        recognise this is a complex problem, and complex problems rarely
        have simple solutions.<br>
      </p>
    </blockquote>
    I don't have a problem with ideologies, it's just that ideologies
    and realities are very often in conflict or even incompatible for
    many reasons.<br>
  </body>
</html>

<p></p>

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

--------------000100090100030403020501--

.

On 2016-03-04 21:22, Miro Knejp wrote:
> Am 04.03.2016 um 20:52 schrieb Patrice Roy:
>> If I may: =C2=ABCode does not get broken because of _expectations_ about
>> order of evaluation.  Code gets written that has _unnoticed_
>> dependency on order of evaluation, but happens to work because the
>> compiler evaluates things in a particular order.  Until one day that
>> order changes=C2=BB sounds more like a plea better code reviews, or for
>> compilers that change evaluation order from time to time in order to
>> ease detection of subtle bugs :) (that was tongue-in-cheek, of course).
> I sometimes wonder whether people saying one should improve the code
> review process think code reviews are magical beings with superhuman
> cognitive powers from another dimension. Last time I checked even
> reviewers were just humans who could make the same mistakes the authors
> did, and fall into the same traps, as happened with Bjarne's book.
> Review is no guarantee for anything.
>>
>> I understand your preoccupation with this issue, but encouraging
>> people to depend on a specific ordering for f() and g() in h(f(), g())
>> (not necessarily in all cases, mind you) instead of encouraging people
>> to avoid inserting dependencies on side-effects between f() and g()
>> does not seem like a fix to me. Similarly, defining the ordering of
>> beasts such as f(i++, i++) does not strike me as something better than
>> encouraging people not to do so.
> The side effect on i in f(i++, i++) is pretty obvious and immediatelly
> apparent. The side effects of g and h in f(g(), h()) are not, especially
> not if you don't have the source code for g and h readily available. So
> a reviewer has to go through the entire expression, go check every
> single function appearing in it and decide whether it has side effect
> dependencies or not. That is also known as a waste of time.
>

This should have been caught already in the code review of g() and h().

If they are supposed to be used together and not only return some=20
values, but also affect the next result of the other function, that is=20
seriously bad design.

Should we really change the language to promote this kind of code?



Bo Persson



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

.

>=20
> This should have been caught already in the code review of g() and h().
>=20
> If they are supposed to be used together and not only return some values,=
 but also affect the next result of the other function, that is seriously b=
ad design.
>=20
> Should we really change the language to promote this kind of code?

That=E2=80=99s naive. g() and h() may come from a third-party library about=
 whose implementation I know next to nothing.

Michi.

--=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/C32AEF5D-DDD8-4E9A-BA8D-CDBD3ABD7E00%40canonical=
..com.

.

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

On 5 March 2016 at 07:18, Michi Henning <michi.henning@canonical.com> wrote=
:

> >
> > This should have been caught already in the code review of g() and h().
> >
> > If they are supposed to be used together and not only return some
> values, but also affect the next result of the other function, that is
> seriously bad design.
> >
> > Should we really change the language to promote this kind of code?
>
> That=E2=80=99s naive. g() and h() may come from a third-party library abo=
ut whose
> implementation I know next to nothing.
>

In other words, it is impossible to know which of

g(); h();

or

h(); g();

is the correct order to call them in.

And somehow, if we had a fixed order of evaluation, f(g(), h()) and f(h(),
g()) would both magically be correct.

By all means, keep these "real world" examples coming...
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +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/CAGg_6%2BPYBgcFov85MazkEf2iF4OEzWiDSDVNC98jMamk3=
VPn6w%40mail.gmail.com.

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

<div dir=3D"ltr">On 5 March 2016 at 07:18, Michi Henning <span dir=3D"ltr">=
&lt;<a href=3D"mailto:michi.henning@canonical.com" target=3D"_blank">michi.=
henning@canonical.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
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"><span class=3D"">&=
gt;<br>
&gt; This should have been caught already in the code review of g() and h()=
..<br>
&gt;<br>
&gt; If they are supposed to be used together and not only return some valu=
es, but also affect the next result of the other function, that is seriousl=
y bad design.<br>
&gt;<br>
&gt; Should we really change the language to promote this kind of code?<br>
<br>
</span>That=E2=80=99s naive. g() and h() may come from a third-party librar=
y about whose implementation I know next to nothing.<br></blockquote><div><=
br></div><div>In other words, it is impossible to know which of</div><div><=
br></div><div>g(); h();</div><div><br></div><div>or</div><div><br></div><di=
v>h(); g();</div><div><br></div><div>is the correct order to call them in.<=
/div><div><br></div><div>And somehow, if we had a fixed order of evaluation=
, f(g(), h()) and f(h(), g()) would both magically be correct.</div><div><b=
r></div><div>By all means, keep these &quot;real world&quot; examples comin=
g...</div></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div=
><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<=
a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlo=
rd.com</a>&gt; =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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPYBgcFov85MazkEf2iF4OEzWiDSD=
VNC98jMamk3VPn6w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPYBgcF=
ov85MazkEf2iF4OEzWiDSDVNC98jMamk3VPn6w%40mail.gmail.com</a>.<br />

--001a11c3c9086ed6d2052d4c7e6f--

.

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

On Sat, Mar 5, 2016 at 7:36 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 5 March 2016 at 07:18, Michi Henning <michi.henning@canonical.com>
> wrote:
>
>> That=E2=80=99s naive. g() and h() may come from a third-party library ab=
out whose
>> implementation I know next to nothing.
>>
>
> In other words, it is impossible to know which of
>
> g(); h();
>
> or
>
> h(); g();
>
> is the correct order to call them in.
>
> And somehow, if we had a fixed order of evaluation, f(g(), h()) and f(h()=
,
> g()) would both magically be correct.
>

That is NOT the point. With a fixed order of evaluation, irrespective of
programmer intent, the code will either fail or succeed consistently. It
wouldn't work 365 days a year and suddenly break because the next version
of the compiler decided to mess up the order.

Why do we keep running in circles 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/CALEPxfvzz%3Dnd0275aML%2BSZOhPNR_qMv3gxfgSatsD_u=
FT6EUJg%40mail.gmail.com.

--001a1141266823e807052d4e0d53
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, Mar 5, 2016 at 7:36 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.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 5 March 2016 at 07:18, Michi Henning <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:michi.henning@canonical.com" target=3D"_blank">michi.henning@canonical.=
com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That=E2=80=99s naive.=
 g() and h() may come from a third-party library about whose implementation=
 I know next to nothing.<br></blockquote><div><br></div></span><div>In othe=
r words, it is impossible to know which of</div><div><br></div><div>g(); h(=
);</div><div><br></div><div>or</div><div><br></div><div>h(); g();</div><div=
><br></div><div>is the correct order to call them in.</div><div><br></div><=
div>And somehow, if we had a fixed order of evaluation, f(g(), h()) and f(h=
(), g()) would both magically be correct.</div></div></div></div></blockquo=
te><div><br></div><div>That is NOT the point. With a fixed order of evaluat=
ion, irrespective of programmer intent, the code will either fail or succee=
d consistently. It wouldn&#39;t work 365 days a year and suddenly break bec=
ause the next version of the compiler decided to mess up the order.</div><d=
iv><br></div><div>Why do we keep running in circles here?</div><div><br></d=
iv></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxfvzz%3Dnd0275aML%2BSZOhPNR_qMv3=
gxfgSatsD_uFT6EUJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfvzz%3D=
nd0275aML%2BSZOhPNR_qMv3gxfgSatsD_uFT6EUJg%40mail.gmail.com</a>.<br />

--001a1141266823e807052d4e0d53--

.

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

On Sat, Mar 5, 2016 at 5:43 AM, Bo Persson <bop@gmb.dk> wrote:

> The side effect on i in f(i++, i++) is pretty obvious and immediatelly
>> apparent. The side effects of g and h in f(g(), h()) are not, especially
>> not if you don't have the source code for g and h readily available. So
>> a reviewer has to go through the entire expression, go check every
>> single function appearing in it and decide whether it has side effect
>> dependencies or not. That is also known as a waste of time.
>>
>>
> This should have been caught already in the code review of g() and h().
>
> If they are supposed to be used together and not only return some values,
> but also affect the next result of the other function, that is seriously
> bad design.
>
> Should we really change the language to promote this kind of code?
>
>
>
A language underspecifying an use-case is somehow being turned into
programmer competency. Sometimes I wonder if these threads are just a place
to vent our argumentative side.

Meanwhile, the authors are quietly pushing for this very change [1] in
standard committee meetings and hoping to get that into the standard while
we debate this stuff until the cows come home.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r1.pdf

--
You received this message because you are 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/CALEPxftu5VMz4wbAzfqsQqG9iyGM2Vk1ZYkANLkNVdQzT_LJTQ%40mail.gmail.com.

--001a114080c008ae91052d4e28c1
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 Sat, Mar 5, 2016 at 5:43 AM, Bo Persson <span dir=3D"ltr">&lt;<a href=3D=
"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-=
left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-le=
ft-style:solid"><div><div class=3D"h5"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,=
204,204);border-left-width:1px;border-left-style:solid">The side effect on =
i in f(i++, i++) is pretty obvious and immediatelly<br>
apparent. The side effects of g and h in f(g(), h()) are not, especially<br=
>
not if you don&#39;t have the source code for g and h readily available. So=
<br>
a reviewer has to go through the entire expression, go check every<br>
single function appearing in it and decide whether it has side effect<br>
dependencies or not. That is also known as a waste of time.<br>
<br>
</blockquote>
<br></div></div><div>
This should have been caught already in the code review of g() and h().<br>
<br>
If they are supposed to be used together and not only return some values, b=
ut also affect the next result of the other function, that is seriously bad=
 design.<br>
<br>
Should we really change the language to promote this kind of code?<br>
<br>
</div><div><br></div></blockquote><div>=C2=A0</div><div>A language underspe=
cifying an use-case is=C2=A0somehow being turned into programmer competency=
.. Sometimes I wonder if these=C2=A0threads=C2=A0are just a place to vent ou=
r argumentative side.=C2=A0</div><div><br></div><div>Meanwhile,=C2=A0the au=
thors are quietly pushing=C2=A0for this very change [1] in standard committ=
ee meetings and hoping to get that into the standard while we debate this s=
tuff until the cows=C2=A0come home.=C2=A0=C2=A0</div><div><br></div><div>[1=
] <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r=
1.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r1.pdf<=
/a></div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxftu5VMz4wbAzfqsQqG9iyGM2Vk1ZYkA=
NLkNVdQzT_LJTQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxftu5VMz4wbA=
zfqsQqG9iyGM2Vk1ZYkANLkNVdQzT_LJTQ%40mail.gmail.com</a>.<br />

--001a114080c008ae91052d4e28c1--

.

Am 05.03.2016 um 11:43 schrieb Bo Persson:
> On 2016-03-04 21:22, Miro Knejp wrote:
>> Am 04.03.2016 um 20:52 schrieb Patrice Roy:
>>> If I may: =C2=ABCode does not get broken because of _expectations_ abou=
t
>>> order of evaluation.  Code gets written that has _unnoticed_
>>> dependency on order of evaluation, but happens to work because the
>>> compiler evaluates things in a particular order.  Until one day that
>>> order changes=C2=BB sounds more like a plea better code reviews, or for
>>> compilers that change evaluation order from time to time in order to
>>> ease detection of subtle bugs :) (that was tongue-in-cheek, of course).
>> I sometimes wonder whether people saying one should improve the code
>> review process think code reviews are magical beings with superhuman
>> cognitive powers from another dimension. Last time I checked even
>> reviewers were just humans who could make the same mistakes the authors
>> did, and fall into the same traps, as happened with Bjarne's book.
>> Review is no guarantee for anything.
>>>
>>> I understand your preoccupation with this issue, but encouraging
>>> people to depend on a specific ordering for f() and g() in h(f(), g())
>>> (not necessarily in all cases, mind you) instead of encouraging people
>>> to avoid inserting dependencies on side-effects between f() and g()
>>> does not seem like a fix to me. Similarly, defining the ordering of
>>> beasts such as f(i++, i++) does not strike me as something better than
>>> encouraging people not to do so.
>> The side effect on i in f(i++, i++) is pretty obvious and immediatelly
>> apparent. The side effects of g and h in f(g(), h()) are not, especially
>> not if you don't have the source code for g and h readily available. So
>> a reviewer has to go through the entire expression, go check every
>> single function appearing in it and decide whether it has side effect
>> dependencies or not. That is also known as a waste of time.
>>
>
> This should have been caught already in the code review of g() and h().
Assuming g() and h() are not from closed-source third party software.=20
And if not you still assume the reviewer recognizes the problem. It=20
assumes the reviewer is experienced enough to know about evaluation=20
order. It assumes the code reviewer is not subconciusly primed to not=20
see a problem because they know from the commit message what it's=20
supposed to do.

Constantly chanting "this should not pass code review" does not change=20
the fact that such code *does* pass code review. And once it is reviewed=20
and committed it is rarely looked at again. Code reviewers make mistakes=20
too. How many people need to review a piece of code until everybody is=20
satisfied that it truly does not contain bugs? One? Two? Twenty?

Code review is not a magical fix for everything.
>
> If they are supposed to be used together and not only return some=20
> values, but also affect the next result of the other function, that is=20
> seriously bad design.
In a perfect world nobody would design bad code and all your=20
dependencies would have perfect APIs. I would love to live in such a place.

Why do people think Bjarne & Co keep pushing for language features that=20
make people write "good code by default"? Because right now it is way=20
too easy to write bad code by default.

--=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/56DB344B.8020507%40gmail.com.

.

This has become a somewhat heated debate.
One quite important consequence of having an unspecified order of
evaluation is that bugs get more difficult to find. Assuming that we
keep the current state, the consequence is that upgrading or changing
a compiler  or changing the optimization options can break code that
would be perfectly good with a fixed order of evaluation. This fact
alone could be a reason to rule out C++ as the language of choice for
many critical applications, e.g. within healthcare or aviation.

I believe we should acknowledge the fact that we are not perfect.
Programmers and code reviewers all make mistakes and removing one
source of error will for sure reduce the amount of errors in shipped
code. To me correctness is important enough that I do not believe
there is any reason to think twice before deciding to have a fixed
evaluation order. What that order should be, I have no strong opinions
about.

/Peter

On Sat, Mar 5, 2016 at 8:32 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
> Am 05.03.2016 um 11:43 schrieb Bo Persson:
>>
>> On 2016-03-04 21:22, Miro Knejp wrote:
>>>
>>> Am 04.03.2016 um 20:52 schrieb Patrice Roy:
>>>>
>>>> If I may: =C2=ABCode does not get broken because of _expectations_ abo=
ut
>>>> order of evaluation.  Code gets written that has _unnoticed_
>>>> dependency on order of evaluation, but happens to work because the
>>>> compiler evaluates things in a particular order.  Until one day that
>>>> order changes=C2=BB sounds more like a plea better code reviews, or fo=
r
>>>> compilers that change evaluation order from time to time in order to
>>>> ease detection of subtle bugs :) (that was tongue-in-cheek, of course)=
..
>>>
>>> I sometimes wonder whether people saying one should improve the code
>>> review process think code reviews are magical beings with superhuman
>>> cognitive powers from another dimension. Last time I checked even
>>> reviewers were just humans who could make the same mistakes the authors
>>> did, and fall into the same traps, as happened with Bjarne's book.
>>> Review is no guarantee for anything.
>>>>
>>>>
>>>> I understand your preoccupation with this issue, but encouraging
>>>> people to depend on a specific ordering for f() and g() in h(f(), g())
>>>> (not necessarily in all cases, mind you) instead of encouraging people
>>>> to avoid inserting dependencies on side-effects between f() and g()
>>>> does not seem like a fix to me. Similarly, defining the ordering of
>>>> beasts such as f(i++, i++) does not strike me as something better than
>>>> encouraging people not to do so.
>>>
>>> The side effect on i in f(i++, i++) is pretty obvious and immediatelly
>>> apparent. The side effects of g and h in f(g(), h()) are not, especiall=
y
>>> not if you don't have the source code for g and h readily available. So
>>> a reviewer has to go through the entire expression, go check every
>>> single function appearing in it and decide whether it has side effect
>>> dependencies or not. That is also known as a waste of time.
>>>
>>
>> This should have been caught already in the code review of g() and h().
>
> Assuming g() and h() are not from closed-source third party software. And=
 if
> not you still assume the reviewer recognizes the problem. It assumes the
> reviewer is experienced enough to know about evaluation order. It assumes
> the code reviewer is not subconciusly primed to not see a problem because
> they know from the commit message what it's supposed to do.
>
> Constantly chanting "this should not pass code review" does not change th=
e
> fact that such code *does* pass code review. And once it is reviewed and
> committed it is rarely looked at again. Code reviewers make mistakes too.
> How many people need to review a piece of code until everybody is satisfi=
ed
> that it truly does not contain bugs? One? Two? Twenty?
>
> Code review is not a magical fix for everything.
>>
>>
>> If they are supposed to be used together and not only return some values=
,
>> but also affect the next result of the other function, that is seriously=
 bad
>> design.
>
> In a perfect world nobody would design bad code and all your dependencies
> would have perfect APIs. I would love to live in such a place.
>
> Why do people think Bjarne & Co keep pushing for language features that m=
ake
> people write "good code by default"? Because right now it is way too easy=
 to
> write bad code by default.
>
> --
> You received this message because you are 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/56DB344B.802=
0507%40gmail.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/CANPtkny32_Bd1e60bd47H3kgx%3DjaT6rXerM0Wfn4FT5LU=
COoDw%40mail.gmail.com.

.

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

On 6 Mar 2016 03:30, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> In a perfect world nobody would design bad code and all your dependencies
would have perfect APIs. I would love to live in such a place.

This place exists, your sarcasm notwithstanding.

> Why do people think Bjarne & Co keep pushing for language features that
make people write "good code by default"? Because right now it is way too
easy to write bad code by default.

So you propose to... make it even easier to write bad code by default? At
least currently code depending on evaluation order can be detected when it
breaks.

--
You received this message because you are 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/CAJnLdOaH43bjeRUZthc3oE4ywX-cZA4cHV_dba8CpXRcHbBiug%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 6 Mar 2016 03:30, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; In a perfect world nobody would design bad code and all your dependenc=
ies would have perfect APIs. I would love to live in such a place.</p>
<p dir=3D"ltr">This place exists, your sarcasm notwithstanding. </p>
<p dir=3D"ltr">&gt; Why do people think Bjarne &amp; Co keep pushing for la=
nguage features that make people write &quot;good code by default&quot;? Be=
cause right now it is way too easy to write bad code by default.</p>
<p dir=3D"ltr">So you propose to... make it even easier to write bad code b=
y default? At least currently code depending on evaluation order can be det=
ected when it breaks. </p>

<p></p>

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

--001a113ecbe488ac42052d61eb86--

.

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

On 6 Mar 2016 17:36, "Peter Koch Larsen" <peter.koch.larsen@gmail.com>
wrote:
>
> This has become a somewhat heated debate.
> One quite important consequence of having an unspecified order of
> evaluation is that bugs get more difficult to find. Assuming that we
> keep the current state, the consequence is that upgrading or changing
> a compiler  or changing the optimization options can break code that
> would be perfectly good with a fixed order of evaluation. This fact
> alone could be a reason to rule out C++ as the language of choice for
> many critical applications, e.g. within healthcare or aviation.
>

I simply don't understand this position. There are so many unspecified or
undefined points of behavior of in the core language and standard library;
why should order of evaluation be the straw that breaks the camel's back?

--
You received this message because you are 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/CAJnLdOa5-jtqxDG7-yYegFvNrN8ONaqrONdknscWm%3De0PFyFaA%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 6 Mar 2016 17:36, &quot;Peter Koch Larsen&quot; &lt;<a href=3D"mailto:pe=
ter.koch.larsen@gmail.com">peter.koch.larsen@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; This has become a somewhat heated debate.<br>
&gt; One quite important consequence of having an unspecified order of<br>
&gt; evaluation is that bugs get more difficult to find. Assuming that we<b=
r>
&gt; keep the current state, the consequence is that upgrading or changing<=
br>
&gt; a compiler=C2=A0 or changing the optimization options can break code t=
hat<br>
&gt; would be perfectly good with a fixed order of evaluation. This fact<br=
>
&gt; alone could be a reason to rule out C++ as the language of choice for<=
br>
&gt; many critical applications, e.g. within healthcare or aviation.<br>
&gt;</p>
<p dir=3D"ltr">I simply don&#39;t understand this position. There are so ma=
ny unspecified or undefined points of behavior of in the core language and =
standard library; why should order of evaluation be the straw that breaks t=
he camel&#39;s back? </p>

<p></p>

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

--001a1140f750cecdc0052d620215--

.

This is a multi-part message in MIME format.
--------------060106060900050806030307
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 06.03.2016 um 15:11 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>
> On 6 Mar 2016 03:30, "Miro Knejp" <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
> >
> > In a perfect world nobody would design bad code and all your
> dependencies would have perfect APIs. I would love to live in such a
> place.
>
> This place exists, your sarcasm notwithstanding.
>
It's great that such places exist. Unfortunately not all of the millions
of companies out there writing C++ code are like that. And some of those
companies may produce code that gets used in lots of places. I can tell
you that in the aviation industry there are many companies who have a
quasi monopoly when it comes to the devices installed at airports
worldwide and these companies provide APIs which you are forced to use
because there is no alternative. These companies aren't filled with the
kind of world-class experts we know from the standardization forums or
speakers at C++ events, they have largely "average" C++ developers who
happily continue writing Java++ because that's the best they know and
either nobody cares to change that or management won't allow. Those who
want change but can't get it leave and are replaced by some other drone
who has to follow shitty existing coding guidelines. That is the reality
of C++ in the world, not those tiny little perfect companies you mention
and we'd all like to have.
>
> > Why do people think Bjarne & Co keep pushing for language features
> that make people write "good code by default"? Because right now it is
> way too easy to write bad code by default.
>
> So you propose to... make it even easier to write bad code by default?
> At least currently code depending on evaluation order can be detected
> when it breaks.
>
WTF? The code is only bad because it depends on something that is
undefined. If the order *is* defined it's no longer bad (certainly not
world-breaking bad). It's really fascinating how the association to bad
code is upheld even if the conditions that make the code bad in the
first place no longer existed. It used to be bad code to return objects
by value but now that we have moves the cause for the bad code is gone
and it is now considered good code, and it's still difficult for people
to grasp and adapt who have avoided such code like the plague for 20+
years. Best practices change along changes to the language and library.

It "can" be detecten when it breaks, sure. Maybe. If the planets are
aligned so your compiler has a bad day. Or maybe the bug doesn't surface
for years and then, suddenly, disaster. That's the whole point of this
discussion. Bugs which cannot be deterministically reproduced on every
developer's machine are the worst kind of bugs. Even worse is not
knowing there is a bug at all until it's too late.

So far the side opposing a fixed order of evaluation has failed to
provide any examples that clearly demonstrate where unspecified order of
evaluation is deliberately intended by the author, and important to the
correctness or the efficiency of the code, bar some toy examples. All
the arguments put forth so far go along the line of "don't be a scrub
you fool and don't make mistakes". That is a very elitist stance to
have. Is that what the C++ community is these days? A bunch of
decade-long experts who don't want to make changes to the language
because, really, you just have to "get good", regardless how difficult
that is for apprentices. Can't have newcomers have it easier than we
did, right? Is that what we're going to teach students now? "Just don't
make mistakes and you'll be fine, oh and make sure to study this 1300
pages standardese document so you know all the rules and edge cases, and
don't you dare forget a single rule lest you be considered a bad
programmer".

--
You received this message because you are 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/56DC51D0.2010501%40gmail.com.

--------------060106060900050806030307
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 06.03.2016 um 15:11 schrieb 'Edward Catmur' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CAJnLdOaH43bjeRUZthc3oE4ywX-cZA4cHV_dba8CpXRcHbBiug@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr"><br>
        On 6 Mar 2016 03:30, "Miro Knejp" &lt;<a moz-do-not-send=3D"true"
          href=3D"mailto:miro.knejp@gmail.com">miro.knejp@gmail.com</a>&gt;
        wrote:<br>
        &gt;<br>
        &gt; In a perfect world nobody would design bad code and all
        your dependencies would have perfect APIs. I would love to live
        in such a place.</p>
      <p dir=3D"ltr">This place exists, your sarcasm notwithstanding. </p>
    </blockquote>
    It's great that such places exist. Unfortunately not all of the
    millions of companies out there writing C++ code are like that. And
    some of those companies may produce code that gets used in lots of
    places. I can tell you that in the aviation industry there are many
    companies who have a quasi monopoly when it comes to the devices
    installed at airports worldwide and these companies provide APIs
    which you are forced to use because there is no alternative. These
    companies aren't filled with the kind of world-class experts we know
    from the standardization forums or speakers at C++ events, they have
    largely "average" C++ developers who happily continue writing Java++
    because that's the best they know and either nobody cares to change
    that or management won't allow. Those who want change but can't get
    it leave and are replaced by some other drone who has to follow
    shitty existing coding guidelines. That is the reality of C++ in the
    world, not those tiny little perfect companies you mention and we'd
    all like to have.<br>
    <blockquote
cite=3D"mid:CAJnLdOaH43bjeRUZthc3oE4ywX-cZA4cHV_dba8CpXRcHbBiug@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr">&gt; Why do people think Bjarne &amp; Co keep pushing
        for language features that make people write "good code by
        default"? Because right now it is way too easy to write bad code
        by default.</p>
      <p dir=3D"ltr">So you propose to... make it even easier to write bad
        code by default? At least currently code depending on evaluation
        order can be detected when it breaks. </p>
    </blockquote>
    WTF? The code is only bad because it depends on something that is
    undefined. If the order *is* defined it's no longer bad (certainly
    not world-breaking bad). It's really fascinating how the association
    to bad code is upheld even if the conditions that make the code bad
    in the first place no longer existed. It used to be bad code to
    return objects by value but now that we have moves the cause for the
    bad code is gone and it is now considered good code, and it's still
    difficult for people to grasp and adapt who have avoided such code
    like the plague for 20+ years. Best practices change along changes
    to the language and library.<br>
    <br>
    It "can" be detecten when it breaks, sure. Maybe. If the planets are
    aligned so your compiler has a bad day. Or maybe the bug doesn't
    surface for years and then, suddenly, disaster. That's the whole
    point of this discussion. Bugs which cannot be deterministically
    reproduced on every developer's machine are the worst kind of bugs.
    Even worse is not knowing there is a bug at all until it's too late.<br=
>
    <br>
    So far the side opposing a fixed order of evaluation has failed to
    provide any examples that clearly demonstrate where unspecified
    order of evaluation is deliberately intended by the author, and
    important to the correctness or the efficiency of the code, bar some
    toy examples. All the arguments put forth so far go along the line
    of "don't be a scrub you fool and don't make mistakes". That is a
    very elitist stance to have. Is that what the C++ community is these
    days? A bunch of decade-long experts who don't want to make changes
    to the language because, really, you just have to "get good",
    regardless how difficult that is for apprentices. Can't have
    newcomers have it easier than we did, right? Is that what we're
    going to teach students now? "Just don't make mistakes and you'll be
    fine, oh and make sure to study this 1300 pages standardese document
    so you know all the rules and edge cases, and don't you dare forget
    a single rule lest you be considered a bad programmer".<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/56DC51D0.2010501%40gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/ms=
gid/std-proposals/56DC51D0.2010501%40gmail.com</a>.<br />

--------------060106060900050806030307--

.

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

On Sun, Mar 6, 2016 at 10:50 AM, Miro Knejp <miro.knejp@gmail.com> wrote:

> Am 06.03.2016 um 15:11 schrieb 'Edward Catmur' via ISO C++ Standard -
> Future Proposals:
>
>
> On 6 Mar 2016 03:30, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
>
> It "can" be detecten when it breaks, sure. Maybe. If the planets are
> aligned so your compiler has a bad day. Or maybe the bug doesn't surface
> for years and then, suddenly, disaster. That's the whole point of this
> discussion. Bugs which cannot be deterministically reproduced on every
> developer's machine are the worst kind of bugs. Even worse is not knowing
> there is a bug at all until it's too late.
>

This point was made and made and made a gazillion different times. The only
argument against that was it will prevent the compiler from making some
sort of optimization that a defined order would preclude it from doing. I
mean, that may be a valid argument but without a concrete example it is
hard to quantify the effect of what we are missing w/o such optimizations.
I don't even consider what you wrote far-fetched because we personally ran
into this very issue just this January (as Hyman, who is a colleague, has
been pointing out).


>
> So far the side opposing a fixed order of evaluation has failed to provide
> any examples that clearly demonstrate where unspecified order of evaluation
> is deliberately intended by the author, and important to the correctness or
> the efficiency of the code, bar some toy examples.
>

As I (or Michi for that matter) never tire of repeating,  <
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r1.pdf> is making
matters worse by laying down different rules (L2R for function argument
evaluation, something else in other cases) for different circumstances. I
believe that paper is trying to strike a compromise between keeping it
unspecified in all cases vs strictly adhering to only one way of evaluating
(L2R). I don't know if that is the way to go though.

--
You received this message because you are 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/CALEPxfst%3D-0Fem7eAO2tqw%3DJoAk%2BXva8oU55tPYX2sbYX9toKQ%40mail.gmail.com.

--001a11c25934361e6c052d63d24f
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, Mar 6, 2016 at 10:50 AM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wi=
dth:1px;border-left-style:solid">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF"><span>
    Am 06.03.2016 um 15:11 schrieb &#39;Edward Catmur&#39; via ISO C++ Stan=
dard
    - Future Proposals:<br>
    <blockquote type=3D"cite">
      <p dir=3D"ltr"><br>
        On 6 Mar 2016 03:30, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:m=
iro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;
        wrote:<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </p></blockquote></span>
    It &quot;can&quot; be detecten when it breaks, sure. Maybe. If the plan=
ets are
    aligned so your compiler has a bad day. Or maybe the bug doesn&#39;t
    surface for years and then, suddenly, disaster. That&#39;s the whole
    point of this discussion. Bugs which cannot be deterministically
    reproduced on every developer&#39;s machine are the worst kind of bugs.
    Even worse is not knowing there is a bug at all until it&#39;s too late=
..<br></div></blockquote><div><br></div><div>This point was made and made an=
d made a gazillion different times. The only argument against that was it w=
ill prevent the compiler from making some sort of optimization that a defin=
ed order would preclude it from doing. I mean, that may be a valid argument=
 but without a concrete example it is hard to quantify the effect of what w=
e are missing w/o such optimizations. I don&#39;t even consider what you wr=
ote far-fetched because we personally ran into this very issue just this Ja=
nuary (as Hyman, who is a colleague, has been pointing out).</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <br>
    So far the side opposing a fixed order of evaluation has failed to
    provide any examples that clearly demonstrate where unspecified
    order of evaluation is deliberately intended by the author, and
    important to the correctness or the efficiency of the code, bar some
    toy examples.<br></div></blockquote><div><br></div><div>As I (or Michi =
for that matter) never tire of repeating,=C2=A0=C2=A0&lt;<a href=3D"http://=
open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r1.pdf">http://open-std.o=
rg/JTC1/SC22/WG21/docs/papers/2016/p0145r1.pdf</a>&gt; is making matters wo=
rse by laying down different rules (L2R for function argument evaluation, s=
omething else in other cases) for different circumstances. I believe that p=
aper is trying to strike a compromise between keeping it unspecified in all=
 cases vs strictly adhering to only one way of evaluating (L2R). I don&#39;=
t know if that is the way to go though.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxfst%3D-0Fem7eAO2tqw%3DJoAk%2BXv=
a8oU55tPYX2sbYX9toKQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfst%3=
D-0Fem7eAO2tqw%3DJoAk%2BXva8oU55tPYX2sbYX9toKQ%40mail.gmail.com</a>.<br />

--001a11c25934361e6c052d63d24f--

.

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

I know people take this issue to heart, but I think it would be preferable
for the debate if we collectively kept wording =C2=ABcalmed down=C2=BB.

There are C++ idioms based on evaluation order, such as =C2=ABif (p && p->f=
())
for some pointer p that checks whether it's null before using it. I doubt
anyone would claim that such idioms are =C2=ABa bad thing=C2=BB as they are
integrated in practice and have been for decades. It becomes annoying when
someone overloads operator&& but apart from this, it works well and sets a
nice precedent of code relying on evaluation order. There are others, of
course, particularly with respect to operators.

I think the point that some have made that they feel f(g(), h()) should
have a well-defined order for g() and h() is clear. I don't have to agree
with it but it's a clear point, and we'll most probably hear it in the
discussions we'll have in Oulu as the proposal for evaluation order should
be brought up there. Maybe it will convince people better than it convinced
me, we'll see. I have never seen the undefined ordering of g() and h() in
such a case as expert-level knowledge (most of my students, if not all,
learn that from the start), but I believe those who say their experience
differs.

I understand the potential efficiency loss argument with respect to the
current undefined ordering. I'd need to see numbers, though, to be
convinced. If we get [[pure]], this argument will be strengthened a bit (we
could not evaluate sume functions that have been memoized, for example),
but that's an =C2=ABif=C2=BB.

The fact that depending on this newly-defined order risks becoming
idiomatic is what worries me, and many others. As stated previously, this
would make such things as f(i++,i++) acceptable practice with respect to
the standard (even if not according to many coding standards) given that
operator++(int) can be overloaded.

As most vocal proponents of the =C2=ABstrong ordering=C2=BB position have s=
tated the
fact that code reviews and available programming expertise as one of the
main reasons (along with dependence on opaque libraries where side-effects
are not documented) why telling their colleagues not to write code which
depends on undefined evaluation order is not sufficient in their opinion,
I'm guessing the point holds for f(i++,i++) or for f(g(i++), h(i++)) or...
and that the same companies that ask for defined ordering in the
contentious cases here would face similar quality control problems with
defined ordering as without. If we open that can of worms, we have to
accept the consequences, which deserves some collective though.

The difference with imposed ordering would be consistency in code
functioning or code crashing; an unwanted (to me at least) consequence
would be that such things as f(g(i++), h(i++)) would become legitimate
(probably not idiomatic at first, but no reason for it not to be at this
point). It's part of the reflection we'll have to make. I see that sort of
code in C# programs when students choose that language, and they claim
(rightfully) that it's allowed and well-defined. I recommend not to do such
obscure things, but cannot fault their reasoning on a technical basis.

The world won't crash if we define these beasts, and it's clearly not
crashing today. It has nice and not-so-nice consequences on the code that
people will write. Since I don't share the impression of the =C2=ABstrong
ordering=C2=BB proponents that it's expert-level stuff to avoid f(g(), h())
cases, I must admit the not-so-nice consequences of defining the order of
evaluation there seem more important to me than the upsides of defining
this order, but my voice will only be one of many.

Cheers!





2016-03-06 10:50 GMT-05:00 Miro Knejp <miro.knejp@gmail.com>:

> Am 06.03.2016 um 15:11 schrieb 'Edward Catmur' via ISO C++ Standard -
> Future Proposals:
>
>
> On 6 Mar 2016 03:30, "Miro Knejp" <miro.knejp@gmail.com> wrote:
> >
> > In a perfect world nobody would design bad code and all your
> dependencies would have perfect APIs. I would love to live in such a plac=
e.
>
> This place exists, your sarcasm notwithstanding.
>
> It's great that such places exist. Unfortunately not all of the millions
> of companies out there writing C++ code are like that. And some of those
> companies may produce code that gets used in lots of places. I can tell y=
ou
> that in the aviation industry there are many companies who have a quasi
> monopoly when it comes to the devices installed at airports worldwide and
> these companies provide APIs which you are forced to use because there is
> no alternative. These companies aren't filled with the kind of world-clas=
s
> experts we know from the standardization forums or speakers at C++ events=
,
> they have largely "average" C++ developers who happily continue writing
> Java++ because that's the best they know and either nobody cares to chang=
e
> that or management won't allow. Those who want change but can't get it
> leave and are replaced by some other drone who has to follow shitty
> existing coding guidelines. That is the reality of C++ in the world, not
> those tiny little perfect companies you mention and we'd all like to have=
..
>
> > Why do people think Bjarne & Co keep pushing for language features that
> make people write "good code by default"? Because right now it is way too
> easy to write bad code by default.
>
> So you propose to... make it even easier to write bad code by default? At
> least currently code depending on evaluation order can be detected when i=
t
> breaks.
>
> WTF? The code is only bad because it depends on something that is
> undefined. If the order *is* defined it's no longer bad (certainly not
> world-breaking bad). It's really fascinating how the association to bad
> code is upheld even if the conditions that make the code bad in the first
> place no longer existed. It used to be bad code to return objects by valu=
e
> but now that we have moves the cause for the bad code is gone and it is n=
ow
> considered good code, and it's still difficult for people to grasp and
> adapt who have avoided such code like the plague for 20+ years. Best
> practices change along changes to the language and library.
>
> It "can" be detecten when it breaks, sure. Maybe. If the planets are
> aligned so your compiler has a bad day. Or maybe the bug doesn't surface
> for years and then, suddenly, disaster. That's the whole point of this
> discussion. Bugs which cannot be deterministically reproduced on every
> developer's machine are the worst kind of bugs. Even worse is not knowing
> there is a bug at all until it's too late.
>
> So far the side opposing a fixed order of evaluation has failed to provid=
e
> any examples that clearly demonstrate where unspecified order of evaluati=
on
> is deliberately intended by the author, and important to the correctness =
or
> the efficiency of the code, bar some toy examples. All the arguments put
> forth so far go along the line of "don't be a scrub you fool and don't ma=
ke
> mistakes". That is a very elitist stance to have. Is that what the C++
> community is these days? A bunch of decade-long experts who don't want to
> make changes to the language because, really, you just have to "get good"=
,
> regardless how difficult that is for apprentices. Can't have newcomers ha=
ve
> it easier than we did, right? Is that what we're going to teach students
> now? "Just don't make mistakes and you'll be fine, oh and make sure to
> study this 1300 pages standardese document so you know all the rules and
> edge cases, and don't you dare forget a single rule lest you be considere=
d
> a bad programmer".
>
> --
> You received this message because you are 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/56DC51D0.201=
0501%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56DC51D0.20=
10501%40gmail.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/CAKiZDp1wAoVsmn8iUA7ZHK6Khqekpt%3DUu_CDyFpUf-Ghf=
nWSBQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div><div>I know people take this issue to heart, but=
 I think it would be preferable for the debate if we collectively kept word=
ing =C2=ABcalmed down=C2=BB.<br><br></div>There are C++ idioms based on eva=
luation order, such as =C2=ABif (p &amp;&amp; p-&gt;f()) for some pointer p=
 that checks whether it&#39;s null before using it. I doubt anyone would cl=
aim that such idioms are =C2=ABa bad thing=C2=BB as they are integrated in =
practice and have been for decades. It becomes annoying when someone overlo=
ads operator&amp;&amp; but apart from this, it works well and sets a nice p=
recedent of code relying on evaluation order. There are others, of course, =
particularly with respect to operators.<br><br></div>I think the point that=
 some have made that they feel f(g(), h()) should have a well-defined order=
 for g() and h() is clear. I don&#39;t have to agree with it but it&#39;s a=
 clear point, and we&#39;ll most probably hear it in the discussions we&#39=
;ll have in Oulu as the proposal for evaluation order should be brought up =
there. Maybe it will convince people better than it convinced me, we&#39;ll=
 see. I have never seen the undefined ordering of g() and h() in such a cas=
e as expert-level knowledge (most of my students, if not all, learn that fr=
om the start), but I believe those who say their experience differs.<br><br=
></div><div>I understand the potential efficiency loss argument with respec=
t to the current undefined ordering. I&#39;d need to see numbers, though, t=
o be convinced. If we get [[pure]], this argument will be strengthened a bi=
t (we could not evaluate sume functions that have been memoized, for exampl=
e), but that&#39;s an =C2=ABif=C2=BB.<br></div><div><br>The fact that depen=
ding on this newly-defined order risks becoming idiomatic is what worries m=
e, and many others. As stated previously, this would make such things as f(=
i++,i++) acceptable practice with respect to the standard (even if not acco=
rding to many coding standards) given that operator++(int) can be overloade=
d.<br><br>As most vocal proponents of the =C2=ABstrong ordering=C2=BB posit=
ion have stated the fact that code reviews and available programming expert=
ise as one of the main reasons (along with dependence on opaque libraries w=
here side-effects are not documented) why telling their colleagues not to w=
rite code which depends on undefined evaluation order is not sufficient in =
their opinion, I&#39;m guessing the point holds for f(i++,i++) or for f(g(i=
++), h(i++)) or... and that the same companies that ask for defined orderin=
g in the contentious cases here would face similar quality control problems=
 with defined ordering as without. If we open that can of worms, we have to=
 accept the consequences, which deserves some collective though.<br><br>The=
 difference with imposed ordering would be consistency in code functioning =
or code crashing; an unwanted (to me at least) consequence would be that su=
ch things as f(g(i++), h(i++)) would become legitimate (probably not idioma=
tic at first, but no reason for it not to be at this point). It&#39;s part =
of the reflection we&#39;ll have to make. I see that sort of code in C# pro=
grams when students choose that language, and they claim (rightfully) that =
it&#39;s allowed and well-defined. I recommend not to do such obscure thing=
s, but cannot fault their reasoning on a technical basis.<br><br></div><div=
>The world won&#39;t crash if we define these beasts, and it&#39;s clearly =
not crashing today. It has nice and not-so-nice consequences on the code th=
at people will write. Since I don&#39;t share the impression of the =C2=ABs=
trong ordering=C2=BB proponents that it&#39;s expert-level stuff to avoid f=
(g(), h()) cases, I must admit the not-so-nice consequences of defining the=
 order of evaluation there seem more important to me than the upsides of de=
fining this order, but my voice will only be one of many.<br><br></div><div=
>Cheers!<br></div><div><br></div><br><div><div><div><div><div><br><br></div=
></div></div></div></div></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">2016-03-06 10:50 GMT-05:00 Miro Knejp <span dir=3D"ltr">&lt;<=
a href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.c=
om</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    Am 06.03.2016 um 15:11 schrieb &#39;Edward Catmur&#39; via ISO C++ Stan=
dard
    - Future Proposals:<br>
    <blockquote type=3D"cite">
      <p dir=3D"ltr"><br>
        On 6 Mar 2016 03:30, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:m=
iro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;
        wrote:<br>
        &gt;<br>
        &gt; In a perfect world nobody would design bad code and all
        your dependencies would have perfect APIs. I would love to live
        in such a place.</p>
      <p dir=3D"ltr">This place exists, your sarcasm notwithstanding. </p>
    </blockquote></span>
    It&#39;s great that such places exist. Unfortunately not all of the
    millions of companies out there writing C++ code are like that. And
    some of those companies may produce code that gets used in lots of
    places. I can tell you that in the aviation industry there are many
    companies who have a quasi monopoly when it comes to the devices
    installed at airports worldwide and these companies provide APIs
    which you are forced to use because there is no alternative. These
    companies aren&#39;t filled with the kind of world-class experts we kno=
w
    from the standardization forums or speakers at C++ events, they have
    largely &quot;average&quot; C++ developers who happily continue writing=
 Java++
    because that&#39;s the best they know and either nobody cares to change
    that or management won&#39;t allow. Those who want change but can&#39;t=
 get
    it leave and are replaced by some other drone who has to follow
    shitty existing coding guidelines. That is the reality of C++ in the
    world, not those tiny little perfect companies you mention and we&#39;d
    all like to have.<span class=3D""><br>
    <blockquote type=3D"cite">
      <p dir=3D"ltr">&gt; Why do people think Bjarne &amp; Co keep pushing
        for language features that make people write &quot;good code by
        default&quot;? Because right now it is way too easy to write bad co=
de
        by default.</p>
      <p dir=3D"ltr">So you propose to... make it even easier to write bad
        code by default? At least currently code depending on evaluation
        order can be detected when it breaks. </p>
    </blockquote></span>
    WTF? The code is only bad because it depends on something that is
    undefined. If the order *is* defined it&#39;s no longer bad (certainly
    not world-breaking bad). It&#39;s really fascinating how the associatio=
n
    to bad code is upheld even if the conditions that make the code bad
    in the first place no longer existed. It used to be bad code to
    return objects by value but now that we have moves the cause for the
    bad code is gone and it is now considered good code, and it&#39;s still
    difficult for people to grasp and adapt who have avoided such code
    like the plague for 20+ years. Best practices change along changes
    to the language and library.<br>
    <br>
    It &quot;can&quot; be detecten when it breaks, sure. Maybe. If the plan=
ets are
    aligned so your compiler has a bad day. Or maybe the bug doesn&#39;t
    surface for years and then, suddenly, disaster. That&#39;s the whole
    point of this discussion. Bugs which cannot be deterministically
    reproduced on every developer&#39;s machine are the worst kind of bugs.
    Even worse is not knowing there is a bug at all until it&#39;s too late=
..<br>
    <br>
    So far the side opposing a fixed order of evaluation has failed to
    provide any examples that clearly demonstrate where unspecified
    order of evaluation is deliberately intended by the author, and
    important to the correctness or the efficiency of the code, bar some
    toy examples. All the arguments put forth so far go along the line
    of &quot;don&#39;t be a scrub you fool and don&#39;t make mistakes&quot=
;. That is a
    very elitist stance to have. Is that what the C++ community is these
    days? A bunch of decade-long experts who don&#39;t want to make changes
    to the language because, really, you just have to &quot;get good&quot;,
    regardless how difficult that is for apprentices. Can&#39;t have
    newcomers have it easier than we did, right? Is that what we&#39;re
    going to teach students now? &quot;Just don&#39;t make mistakes and you=
&#39;ll be
    fine, oh and make sure to study this 1300 pages standardese document
    so you know all the rules and edge cases, and don&#39;t you dare forget
    a single rule lest you be considered a bad programmer&quot;.<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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/56DC51D0.2010501%40gmail.com?utm_medi=
um=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/56DC51D0.2010501%40gmail.com</a>.<b=
r>
</blockquote></div><br></div>

<p></p>

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

--001a1143dd1881914b052d640c6e--

.

Am 06.03.2016 um 17:43 schrieb Patrice Roy:
> I know people take this issue to heart, but I think it would be=20
> preferable for the debate if we collectively kept wording =C2=ABcalmed do=
wn=C2=BB.
>
> There are C++ idioms based on evaluation order, such as =C2=ABif (p &&=20
> p->f()) for some pointer p that checks whether it's null before using=20
> it. I doubt anyone would claim that such idioms are =C2=ABa bad thing=C2=
=BB as=20
> they are integrated in practice and have been for decades. It becomes=20
> annoying when someone overloads operator&& but apart from this, it=20
> works well and sets a nice precedent of code relying on evaluation=20
> order. There are others, of course, particularly with respect to=20
> operators.
>
> I think the point that some have made that they feel f(g(), h())=20
> should have a well-defined order for g() and h() is clear. I don't=20
> have to agree with it but it's a clear point, and we'll most probably=20
> hear it in the discussions we'll have in Oulu as the proposal for=20
> evaluation order should be brought up there. Maybe it will convince=20
> people better than it convinced me, we'll see. I have never seen the=20
> undefined ordering of g() and h() in such a case as expert-level=20
> knowledge (most of my students, if not all, learn that from the=20
> start), but I believe those who say their experience differs.
Unfortunately we cannot ensure all students are tought the same things=20
and come out of college with the same level of knowledge. I believe the=20
fewer rules there are they have to remember the more time and brainpower=20
they have available to solve the actual problem instead of fighting the=20
language, making the whole learning process less frustrating and more=20
enjoyable.
>
> I understand the potential efficiency loss argument with respect to=20
> the current undefined ordering. I'd need to see numbers, though, to be=20
> convinced. If we get [[pure]], this argument will be strengthened a=20
> bit (we could not evaluate sume functions that have been memoized, for=20
> example), but that's an =C2=ABif=C2=BB.
>
> The fact that depending on this newly-defined order risks becoming=20
> idiomatic is what worries me, and many others. As stated previously,=20
> this would make such things as f(i++,i++) acceptable practice with=20
> respect to the standard (even if not according to many coding=20
> standards) given that operator++(int) can be overloaded.
I don't understand the worry. As you have stated yourself, depending on=20
"if(p && p->f())" is considered OK, but why? Because it *is* OK or=20
because it has been done for decades and people got used to it? The=20
current proposal suggests overloaded operators to get the same order as=20
the builtin ones, so that trap would go away. "f(g(), h())" is currently=20
bad because it is undefined and nondeterministic, but if that changes=20
and it *is* defined and deterministic, why is it still bad? If the root=20
cause for the badness is removed, what makes it still bad? I seriously=20
don't understand the line of thought. If, as you say below, students=20
intuitively follow this idiom in C# because they realize it is=20
well-defined, isn't that a sign it is what people actually want to do?=20
So why is it still considered a problem und the new rules?

Is this maybe just a "fear of the new"? Is this new idiom "unwanted"=20
because it contradicts what has been ingrained into our brains over so=20
many years and suddenly that instinct is at risk of becoming obsolete?=20
To paraphrase Bjarne: people first want new features to have verbose=20
syntax, be explicit, and stand out, but once they get used to them they=20
want terse and convenient syntax instead. Is this worry based on the=20
same psychological effect?

In other words: is the opposition to writing such code (after the=20
appropriate language change) based on objective facts or subjective=20
(maybe subconcious) fears?

I am genuinly interested in the reasoning because if there are good=20
technical or psychological reasons against the idiom you describe I want=20
to know them.

A reason I see in favor of the idiom is the fact the compiler can more=20
efficiently treat the temporaries in a case like "f(g(), h())" without=20
me having to do anything special. If people have to sequence the=20
expression with statements they have to litter their code with std::move=20
to give it the same semantics as the compiler would have done by=20
default, and you are forced to introduce single-use variables into your=20
code, which may be a help or hindrance depending on circumstance.

So in order to manually sequence the expression
f(g(), h())

I have to write
auto a =3D g();
auto b =3D h();
f(std::move(a), std::move(b))

The compiler has more freedom with prvalues than it has with xvalues and=20
I can tell from experience that people often forget std::move. Without=20
the move a reviewer has to ask themselves "is this copy deliberate or=20
did they forget to move?". If evaluation order is well-defined then in=20
the single-expression case there is nothing to forget and no ambiguity=20
to worry about. One would do the correct and most efficient thing by=20
default.

--=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/56DC6CC1.2080109%40gmail.com.

.

> On 7 Mar 2016, at 2:43 , Patrice Roy <patricer@gmail.com> wrote:

> Since I don't share the impression of the =C2=ABstrong ordering=C2=BB pro=
ponents that it's expert-level stuff to avoid f(g(), h()) cases, I must adm=
it the not-so-nice consequences of defining the order of evaluation there s=
eem more important to me than the upsides of defining this order, but my vo=
ice will only be one of many.

To me, the biggest problem with the current proposal is that it tries to ha=
ve it both ways, by defining evaluation order in some cases, but not others=
.. The complexity of the new rules is worse than having no defined order at =
all, in my opinion. If there is to be a change to evaluation order, I would=
 much prefer to see that defined universally than seeing it defined partial=
ly.

Michi.

--=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/C3A69845-96A0-46E6-A693-02700BC99101%40canonical=
..com.

.

On 2016-03-06 18:45, Miro Knejp wrote:
>
> So in order to manually sequence the expression
> f(g(), h())
>
> I have to write
> auto a = g();
> auto b = h();
> f(std::move(a), std::move(b))
>
> The compiler has more freedom with prvalues than it has with xvalues and
> I can tell from experience that people often forget std::move. Without
> the move a reviewer has to ask themselves "is this copy deliberate or
> did they forget to move?". If evaluation order is well-defined then in
> the single-expression case there is nothing to forget and no ambiguity
> to worry about. One would do the correct and most efficient thing by
> default.
>

The order of calls is important in f(g(), h()), if calling h() affects
the returned value of g(). The proposed fix is to have a left-to-right
evaluation.


Someone else will no doubt use another function f2(h(), g()), which has
the same problem but will still be broken. So how do we fix that?



    Bo Persson


--
You received this message because you are 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/nbiaen%24onb%241%40ger.gmane.org.

.

On Sun, Mar 06, 2016 at 11:20:07PM +0100, Bo Persson wrote:
> On 2016-03-06 18:45, Miro Knejp wrote:
> >
> >So in order to manually sequence the expression
> >f(g(), h())
> >
> >I have to write
> >auto a = g();
> >auto b = h();
> >f(std::move(a), std::move(b))
> >
> >The compiler has more freedom with prvalues than it has with xvalues and
> >I can tell from experience that people often forget std::move. Without
> >the move a reviewer has to ask themselves "is this copy deliberate or
> >did they forget to move?". If evaluation order is well-defined then in
> >the single-expression case there is nothing to forget and no ambiguity
> >to worry about. One would do the correct and most efficient thing by
> >default.
> >
>
> The order of calls is important in f(g(), h()), if calling h() affects the
> returned value of g(). The proposed fix is to have a left-to-right
> evaluation.
>
>
> Someone else will no doubt use another function f2(h(), g()), which has the
> same problem but will still be broken. So how do we fix that?

I believe that the reasoning here is that the code would be broken once and
then never again as opposed to the current state where it might be "broken" in
each and every compiler release, port or function.

I also get the impression that the LTR crowd could accept RTL easier than
undefined.

/MF

--
You received this message because you are 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/20160306222625.GB2268%40noemi.

.

> On 7 Mar 2016, at 8:20 , Bo Persson <bop@gmb.dk> wrote:
>=20
> The order of calls is important in f(g(), h()), if calling h() affects th=
e returned value of g(). The proposed fix is to have a left-to-right evalua=
tion.
>=20
>=20
> Someone else will no doubt use another function f2(h(), g()), which has t=
he same problem but will still be broken. So how do we fix that?

I don=E2=80=99t think we can. If code today includes both f(g(), h()) and f=
2(h(), g()), it=E2=80=99s broken already. Changing evaluation order will ju=
st make it break differently. Moreover, code that today includes *only* f(g=
(), h()) or *only* f2(h(), g()) is broken too, even it happens to do the ri=
ght thing.

I don=E2=80=99t see a problem with going from undefined to defined order, e=
ven though that might break some existing code. That=E2=80=99s simply becau=
se any code that relies on a particular order today already has undefined b=
ehavior. Defining evaluation order cannot break an existing correct program=
, only an existing incorrect one.

Michi.

--=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/33167C7E-0CF7-436A-AD8B-0638D537447E%40canonical=
..com.

.

--Apple-Mail=_B22311F2-0AD8-46BB-A086-29B1DD75A49F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 7 Mar 2016, at 8:26 , Magnus Fromreide <magfr@lysator.liu.se> wrote:
>=20
> I also get the impression that the LTR crowd could accept RTL easier than
> undefined.

Personally, I wouldn=E2=80=99t like RTL because it=E2=80=99s much less intu=
itive, so I don=E2=80=99t think that would be a good choice. But, yes, I=E2=
=80=99d be happier with RTL than with undefined order.

Michi.

--=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/4CA20CBD-7B10-4C4D-BA75-0A6D9B1E22A0%40canonical=
..com.

--Apple-Mail=_B22311F2-0AD8-46BB-A086-29B1DD75A49F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 7 Mar 2016, at 8:=
26 , Magnus Fromreide &lt;<a href=3D"mailto:magfr@lysator.liu.se" class=3D"=
">magfr@lysator.liu.se</a>&gt; wrote:</div><div class=3D""><br style=3D"fon=
t-family: Helvetica; font-size: 12px; font-style: normal; font-variant: nor=
mal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><sp=
an style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
float: none; display: inline !important;" class=3D"">I also get the impress=
ion that the LTR crowd could accept RTL easier than</span><br style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; orphans: auto; text-align:=
 start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><spa=
n style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
 normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; f=
loat: none; display: inline !important;" class=3D"">undefined.</span><br st=
yle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-va=
riant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: nor=
mal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" clas=
s=3D""></div></blockquote><div><br class=3D""></div>Personally, I wouldn=E2=
=80=99t like RTL because it=E2=80=99s much less intuitive, so I don=E2=80=
=99t think that would be a good choice. But, yes, I=E2=80=99d be happier wi=
th RTL than with undefined order.</div><div><br class=3D""></div><div>Michi=
..</div></body></html>

<p></p>

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

--Apple-Mail=_B22311F2-0AD8-46BB-A086-29B1DD75A49F--

.

On Sun, Mar 06, 2016 at 11:43:32AM -0500, Patrice Roy wrote:
> I know people take this issue to heart, but I think it would be preferabl=
e
> for the debate if we collectively kept wording =C2=ABcalmed down=C2=BB.
>=20
> There are C++ idioms based on evaluation order, such as =C2=ABif (p && p-=
>f())
> for some pointer p that checks whether it's null before using it. I doubt
> anyone would claim that such idioms are =C2=ABa bad thing=C2=BB as they a=
re
> integrated in practice and have been for decades. It becomes annoying whe=
n
> someone overloads operator&& but apart from this, it works well and sets =
a
> nice precedent of code relying on evaluation order. There are others, of
> course, particularly with respect to operators.
>=20
> I think the point that some have made that they feel f(g(), h()) should
> have a well-defined order for g() and h() is clear. I don't have to agree
> with it but it's a clear point, and we'll most probably hear it in the
> discussions we'll have in Oulu as the proposal for evaluation order shoul=
d
> be brought up there. Maybe it will convince people better than it convinc=
ed
> me, we'll see. I have never seen the undefined ordering of g() and h() in
> such a case as expert-level knowledge (most of my students, if not all,
> learn that from the start), but I believe those who say their experience
> differs.
>=20
> I understand the potential efficiency loss argument with respect to the
> current undefined ordering. I'd need to see numbers, though, to be
> convinced. If we get [[pure]], this argument will be strengthened a bit (=
we
> could not evaluate sume functions that have been memoized, for example),
> but that's an =C2=ABif=C2=BB.

One thing I havent seen mentioned is that a defined ordering would kill
auto-parallelization, but then I don't know if that is a problem.

/MF

--=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/20160306223041.GC2268%40noemi.

.

>=20
> One thing I havent seen mentioned is that a defined ordering would kill
> auto-parallelization, but then I don't know if that is a problem.

Under an =E2=80=9Cas-if=E2=80=9D rule, at least some auto-parallelization c=
ould remain intact. But auto-parallelization of, say, function arguments wi=
ll probably not optimize much, unless the function arguments do something c=
omplex and worth parallelizing. But, in that case, the compiler almost cert=
ainly can no longer deduce whether it=E2=80=99s safe to parallelize argumen=
t evaluation.

So, I doubt that we=E2=80=99d take much of a hit there at all.

Michi.

--=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/4D2C3470-78A5-4D61-A079-38FD9860ED43%40canonical=
..com.

.

--089e0158aa1c6db7f4052d6a6962
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 7 Mar 2016 06:33, "Michi Henning" <michi.henning@canonical.com> wrote:
>
> >
> > One thing I havent seen mentioned is that a defined ordering would kill
> > auto-parallelization, but then I don't know if that is a problem.
>
> Under an =E2=80=9Cas-if=E2=80=9D rule, at least some auto-parallelization=
 could remain
intact. But auto-parallelization of, say, function arguments will probably
not optimize much, unless the function arguments do something complex and
worth parallelizing. But, in that case, the compiler almost certainly can
no longer deduce whether it=E2=80=99s safe to parallelize argument evaluati=
on.

That's what software transactional memory is for; you optimistically
execute each argument in parallel and check for conflicts at commit. If
there is a conflict (and note that reads from or writes to the same memory
location are fine, as long as no more than one transaction has a read from
followed by a write to that location) you abort and rerun losing
transactions in serial.

Note that this means that evaluation order is not known until runtime, and
then only after the fact.

--=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/CAJnLdObR02sRYHT3Kx2gwea%3DG-acYvQCvN5O_beWkysZK=
fS%2Byw%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 7 Mar 2016 06:33, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; One thing I havent seen mentioned is that a defined ordering woul=
d kill<br>
&gt; &gt; auto-parallelization, but then I don&#39;t know if that is a prob=
lem.<br>
&gt;<br>
&gt; Under an =E2=80=9Cas-if=E2=80=9D rule, at least some auto-parallelizat=
ion could remain intact. But auto-parallelization of, say, function argumen=
ts will probably not optimize much, unless the function arguments do someth=
ing complex and worth parallelizing. But, in that case, the compiler almost=
 certainly can no longer deduce whether it=E2=80=99s safe to parallelize ar=
gument evaluation.</p>
<p dir=3D"ltr">That&#39;s what software transactional memory is for; you op=
timistically execute each argument in parallel and check for conflicts at c=
ommit. If there is a conflict (and note that reads from or writes to the sa=
me memory location are fine, as long as no more than one transaction has a =
read from followed by a write to that location) you abort and rerun losing =
transactions in serial. </p>
<p dir=3D"ltr">Note that this means that evaluation order is not known unti=
l runtime, and then only after the fact. <br>
</p>

<p></p>

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

--089e0158aa1c6db7f4052d6a6962--

.

Am 06.03.2016 um 23:20 schrieb Bo Persson:
> On 2016-03-06 18:45, Miro Knejp wrote:
>>
>> So in order to manually sequence the expression
>> f(g(), h())
>>
>> I have to write
>> auto a = g();
>> auto b = h();
>> f(std::move(a), std::move(b))
>>
>> The compiler has more freedom with prvalues than it has with xvalues and
>> I can tell from experience that people often forget std::move. Without
>> the move a reviewer has to ask themselves "is this copy deliberate or
>> did they forget to move?". If evaluation order is well-defined then in
>> the single-expression case there is nothing to forget and no ambiguity
>> to worry about. One would do the correct and most efficient thing by
>> default.
>>
>
> The order of calls is important in f(g(), h()), if calling h() affects
> the returned value of g(). The proposed fix is to have a left-to-right
> evaluation.
>
>
> Someone else will no doubt use another function f2(h(), g()), which
> has the same problem but will still be broken. So how do we fix that?
Then at least you have a consistently reproducible bug instead of the
current randomness.

--
You received this message because you are 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/56DCCD99.7060808%40gmail.com.

.

Yes, there are (to) many examples of unspecified/undefined behaviour
in the C++ standard, but this one is particularly annoying because it
does not manifest itself as readily. If you e.g. dereference v.end(),
chances are quite good that you will be told during compilation or
testing. Not so with the reordering, where the error might lie
silently in your code for decades and suddenly popup when you change
compiler.

By fixing order of evaluation, I hope to remove one of the unspecified
behaviours. There are more to go, but this one is quite important.

/Peter



On Sun, Mar 6, 2016 at 3:17 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> On 6 Mar 2016 17:36, "Peter Koch Larsen" <peter.koch.larsen@gmail.com>
> wrote:
>>
>> This has become a somewhat heated debate.
>> One quite important consequence of having an unspecified order of
>> evaluation is that bugs get more difficult to find. Assuming that we
>> keep the current state, the consequence is that upgrading or changing
>> a compiler  or changing the optimization options can break code that
>> would be perfectly good with a fixed order of evaluation. This fact
>> alone could be a reason to rule out C++ as the language of choice for
>> many critical applications, e.g. within healthcare or aviation.
>>
>
> I simply don't understand this position. There are so many unspecified or
> undefined points of behavior of in the core language and standard library;
> why should order of evaluation be the straw that breaks the camel's back?
>
> --
> You received this message because you are 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/CAJnLdOa5-jtqxDG7-yYegFvNrN8ONaqrONdknscWm%3De0PFyFaA%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/CANPtknw0fdbwBSvvnm2gFvPBWB7H4wKer_xi%3DPOnTsPHKC0eRg%40mail.gmail.com.

.

--047d7bdca440ed6e05052d765bd0
Content-Type: text/plain; charset=UTF-8

On 6 Mar 2016 18:48, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> So far the side opposing a fixed order of evaluation has failed to
provide any examples that clearly demonstrate where unspecified order of
evaluation is deliberately intended by the author, and important to the
correctness or the efficiency of the code, bar some toy examples.

Bar some toy examples - at least there are examples! What has the
defined-order side provided other than anecdotes and vague references to
private bug reports that even by their own admission omit all useful
details?

--
You received this message because you are 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/CAJnLdObnVc7ZM4_pbPNhDoHAnfPGOwCNGPVGi-YVj07UjhxiyA%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 6 Mar 2016 18:48, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; So far the side opposing a fixed order of evaluation has failed to pro=
vide any examples that clearly demonstrate where unspecified order of evalu=
ation is deliberately intended by the author, and important to the correctn=
ess or the efficiency of the code, bar some toy examples. </p>
<p dir=3D"ltr">Bar some toy examples - at least there are examples! What ha=
s the defined-order side provided other than anecdotes and vague references=
 to private bug reports that even by their own admission omit all useful de=
tails? </p>

<p></p>

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

--047d7bdca440ed6e05052d765bd0--

.

--089e01494c2200378e052d765c5e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 7 Mar 2016 01:28, "Michi Henning" <michi.henning@canonical.com> wrote:
>
> I don=E2=80=99t see a problem with going from undefined to defined order,=
 even
though that might break some existing code. That=E2=80=99s simply because a=
ny code
that relies on a particular order today already has undefined behavior.
Defining evaluation order cannot break an existing correct program, only an
existing incorrect one.
>

How do you handle the inconsistency? When it comes to promoting
defined-order evaluation you trumpet your concern for the travails of
students and industrial-programming unfortunates, but raise the downsides
of your approach and you are ready to throw maintainers under the bus as
callously as your worst stereotype of the defenders of free-order
evaluation.

--=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/CAJnLdOZJB9YV9P8a56mi699E%3DMW-2sGDP0QY_-MBL5Q5i=
SNWPw%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 7 Mar 2016 01:28, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi.=
henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I don=E2=80=99t see a problem with going from undefined to defined ord=
er, even though that might break some existing code. That=E2=80=99s simply =
because any code that relies on a particular order today already has undefi=
ned behavior. Defining evaluation order cannot break an existing correct pr=
ogram, only an existing incorrect one.<br>
&gt;</p>
<p dir=3D"ltr">How do you handle the inconsistency? When it comes to promot=
ing defined-order evaluation you trumpet your concern for the travails of s=
tudents and industrial-programming unfortunates, but raise the downsides of=
 your approach and you are ready to throw maintainers under the bus as call=
ously as your worst stereotype of the defenders of free-order evaluation. <=
/p>

<p></p>

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

--089e01494c2200378e052d765c5e--

.

--047d7bea43fcd50a1d052d765b6e
Content-Type: text/plain; charset=UTF-8

On 7 Mar 2016 01:43, "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> I don't understand the worry. As you have stated yourself, depending on
"if(p && p->f())" is considered OK, but why? Because it *is* OK or because
it has been done for decades and people got used to it? The current
proposal suggests overloaded operators to get the same order as the builtin
ones, so that trap would go away. "f(g(), h())" is currently bad because it
is undefined and nondeterministic, but if that changes and it *is* defined
and deterministic, why is it still bad? If the root cause for the badness
is removed, what makes it still bad? I seriously don't understand the line
of thought. If, as you say below, students intuitively follow this idiom in
C# because they realize it is well-defined, isn't that a sign it is what
people actually want to do? So why is it still considered a problem und the
new rules?

Students write overcomplicated code, to exercise and show off their newly
acquired skills and because they have not yet learnt the pain such code can
cause to maintainers (and, in particular, to their future selves). Indeed,
student code is typically written once and then thrown away, but real world
code is read far more times than it is written, so it should be written for
the convenience of the maintainer, not the initial coder. Typically when I
am in flow I will write some complicated line of code and then have to go
back to revise it before commit, breaking it into pieces that each do one
thing at the appropriate level of abstraction, so that it will be
comprehensible to the reviewer and maintainer.

A function call that performs a side effect to application state and
returns a value is already doing at least two things, so should not be
combined in an expression with function calls doing even more things.

Also, to a maintainer an expression written to a defined evaluation order
is more complex than code written to free evaluation order, because it
potentially implies an ordering dependency between operands, whether or not
that is desired.

> A reason I see in favor of the idiom is the fact the compiler can more
efficiently treat the temporaries in a case like "f(g(), h())" without me
having to do anything special. If people have to sequence the expression
with statements they have to litter their code with std::move to give it
the same semantics as the compiler would have done by default, and you are
forced to introduce single-use variables into your code, which may be a
help or hindrance depending on circumstance.

You would have to do that anyway if the order in which f accepts its
arguments does not coincide under the putatively standardized evaluation
order with the order in which you need g and h to be evaluated, so it's not
much of a win.

--
You received this message because you are 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/CAJnLdOYbLBpqfsKOSz-wqQ6qr5PVyeLFTLkQ0nZ%2Bhmf7DXoFSg%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 7 Mar 2016 01:43, &quot;Miro Knejp&quot; &lt;<a href=3D"mailto:miro.knej=
p@gmail.com">miro.knejp@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I don&#39;t understand the worry. As you have stated yourself, dependi=
ng on &quot;if(p &amp;&amp; p-&gt;f())&quot; is considered OK, but why? Bec=
ause it *is* OK or because it has been done for decades and people got used=
 to it? The current proposal suggests overloaded operators to get the same =
order as the builtin ones, so that trap would go away. &quot;f(g(), h())&qu=
ot; is currently bad because it is undefined and nondeterministic, but if t=
hat changes and it *is* defined and deterministic, why is it still bad? If =
the root cause for the badness is removed, what makes it still bad? I serio=
usly don&#39;t understand the line of thought. If, as you say below, studen=
ts intuitively follow this idiom in C# because they realize it is well-defi=
ned, isn&#39;t that a sign it is what people actually want to do? So why is=
 it still considered a problem und the new rules?</p>
<p dir=3D"ltr">Students write overcomplicated code, to exercise and show of=
f their newly acquired skills and because they have not yet learnt the pain=
 such code can cause to maintainers (and, in particular, to their future se=
lves). Indeed, student code is typically written once and then thrown away,=
 but real world code is read far more times than it is written, so it shoul=
d be written for the convenience of the maintainer, not the initial coder. =
Typically when I am in flow I will write some complicated line of code and =
then have to go back to revise it before commit, breaking it into pieces th=
at each do one thing at the appropriate level of abstraction, so that it wi=
ll be comprehensible to the reviewer and maintainer. </p>
<p dir=3D"ltr">A function call that performs a side effect to application s=
tate and returns a value is already doing at least two things, so should no=
t be combined in an expression with function calls doing even more things. =
</p>
<p dir=3D"ltr">Also, to a maintainer an expression written to a defined eva=
luation order is more complex than code written to free evaluation order, b=
ecause it potentially implies an ordering dependency between operands, whet=
her or not that is desired. </p>
<p dir=3D"ltr">&gt; A reason I see in favor of the idiom is the fact the co=
mpiler can more efficiently treat the temporaries in a case like &quot;f(g(=
), h())&quot; without me having to do anything special. If people have to s=
equence the expression with statements they have to litter their code with =
std::move to give it the same semantics as the compiler would have done by =
default, and you are forced to introduce single-use variables into your cod=
e, which may be a help or hindrance depending on circumstance.</p>
<p dir=3D"ltr">You would have to do that anyway if the order in which f acc=
epts its arguments does not coincide under the putatively standardized eval=
uation order with the order in which you need g and h to be evaluated, so i=
t&#39;s not much of a win. </p>

<p></p>

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

--047d7bea43fcd50a1d052d765b6e--

.

--Apple-Mail=_AB7C1507-44EF-4E7C-B2E9-92B9EB9F570D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 07 Mar 2016, at 15:34 , 'Edward Catmur' via ISO C++ Standard - Future =
Proposals <std-proposals@isocpp.org> wrote:
>=20
>=20
> On 7 Mar 2016 01:28, "Michi Henning" <michi.henning@canonical.com <mailto=
:michi.henning@canonical.com>> wrote:
> >
> > I don=E2=80=99t see a problem with going from undefined to defined orde=
r, even though that might break some existing code. That=E2=80=99s simply b=
ecause any code that relies on a particular order today already has undefin=
ed behavior. Defining evaluation order cannot break an existing correct pro=
gram, only an existing incorrect one.
> >
>=20
> How do you handle the inconsistency? When it comes to promoting defined-o=
rder evaluation you trumpet your concern for the travails of students and i=
ndustrial-programming unfortunates, but raise the downsides of your approac=
h and you are ready to throw maintainers under the bus as callously as your=
 worst stereotype of the defenders of free-order evaluation.
>=20
Code which breaks under this change is bugged already, they just don=E2=80=
=99t know it yet. Those maintainers are already standing on the road, it=E2=
=80=99s just a matter of time for the bus to hit. If the change breaks thei=
r code it can only do them good because it reveals an existing flaw in thei=
r program. Such code is currently playing Russian Roulette and could backfi=
re at any time. You cannot by definition break code relying on undefined be=
havior because anything goes.

Just look at it this way: since evaluation order is currently undefined, th=
e evaluation order proposed for standardization is *already allowed*. All i=
t takes is the compiler to silently change the order in the next update and=
 the code breaks in *exactly the same way* as if this was standardized. The=
 only difference is that you can then reproduce the bug on every conforming=
 compiler.

--=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/6852A51E-7BE7-420C-B630-92B1BEC843B0%40gmail.com=
..

--Apple-Mail=_AB7C1507-44EF-4E7C-B2E9-92B9EB9F570D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 07 Mar 2016, at 1=
5:34 , 'Edward Catmur' via ISO C++ Standard - Future Proposals &lt;<a href=
=3D"mailto:std-proposals@isocpp.org" class=3D"">std-proposals@isocpp.org</a=
>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><=
p dir=3D"ltr" class=3D""><br class=3D"">
On 7 Mar 2016 01:28, "Michi Henning" &lt;<a href=3D"mailto:michi.henning@ca=
nonical.com" class=3D"">michi.henning@canonical.com</a>&gt; wrote:<br class=
=3D"">
&gt;<br class=3D"">
&gt; I don=E2=80=99t see a problem with going from undefined to defined ord=
er, even though that might break some existing code. That=E2=80=99s simply =
because any code that relies on a particular order today already has undefi=
ned behavior. Defining evaluation order cannot break an existing correct pr=
ogram, only an existing incorrect one.<br class=3D"">
&gt;</p><p dir=3D"ltr" class=3D"">How do you handle the inconsistency? When=
 it comes to promoting defined-order evaluation you trumpet your concern fo=
r the travails of students and industrial-programming unfortunates, but rai=
se the downsides of your approach and you are ready to throw maintainers un=
der the bus as callously as your worst stereotype of the defenders of free-=
order evaluation. </p></div></blockquote>Code which breaks under this chang=
e is bugged already, they just don=E2=80=99t know it yet. Those maintainers=
 are already standing on the road, it=E2=80=99s just a matter of time for t=
he bus to hit. If the change breaks their code it can only do them good bec=
ause it reveals an existing flaw in their program. Such code is currently p=
laying Russian Roulette and could backfire at any time. You cannot by defin=
ition break code relying on undefined behavior because anything goes.</div>=
<div><br class=3D""></div><div>Just look at it this way: since evaluation o=
rder is currently undefined, the evaluation order proposed for standardizat=
ion is *already allowed*. All it takes is the compiler to silently change t=
he order in the next update and the code breaks in *exactly the same way* a=
s if this was standardized. The only difference is that you can then reprod=
uce the bug on every conforming compiler.</div></body></html>

<p></p>

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

--Apple-Mail=_AB7C1507-44EF-4E7C-B2E9-92B9EB9F570D--

.

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

I can easily think of a g() and h() that are not "bad" but are still
order-dependent.  They might, for example, be consuming items from a
stream, or writing items to one.

And as @Miro says, we know f(g(), h()) is "bad" because we know it causes
non-deterministic behavior.  Once order of evaluation is defined, depending
on order will no longer be bad, and we can stop warning people about it.

And as for overloaded operator&&, that is another terrible error in the
language design.  The way to fix it, as I have suggested (but not formally
proposed) before, is to define a new form of function parameter tagged with
[], e.g., void f([] int x), which would cause the argument expression to be
wrapped in a special form of lambda that is evaluated within the function
only if the function chooses to evaluate the parameter.  (And we need a
"special form" of lambda because each regular lambda is a different type,
so a function taking lambda parameters needs to be a template; maybe a
std::function could be invisibly interposed...  Oh, C++.  You break my
heart.)

On Sun, Mar 6, 2016 at 7:38 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

> Am 06.03.2016 um 23:20 schrieb Bo Persson:
>
>> On 2016-03-06 18:45, Miro Knejp wrote:
>>
>>>
>>> So in order to manually sequence the expression
>>> f(g(), h())
>>>
>>> I have to write
>>> auto a = g();
>>> auto b = h();
>>> f(std::move(a), std::move(b))
>>>
>>> The compiler has more freedom with prvalues than it has with xvalues and
>>> I can tell from experience that people often forget std::move. Without
>>> the move a reviewer has to ask themselves "is this copy deliberate or
>>> did they forget to move?". If evaluation order is well-defined then in
>>> the single-expression case there is nothing to forget and no ambiguity
>>> to worry about. One would do the correct and most efficient thing by
>>> default.
>>>
>>>
>> The order of calls is important in f(g(), h()), if calling h() affects
>> the returned value of g(). The proposed fix is to have a left-to-right
>> evaluation.
>>
>>
>> Someone else will no doubt use another function f2(h(), g()), which has
>> the same problem but will still be broken. So how do we fix that?
>>
> Then at least you have a consistently reproducible bug instead of the
> current randomness.
>
> --
> You received this message because you are 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/56DCCD99.7060808%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/CAHSYqdaSyy7e0qSSvaoMyzyCR04tRODis3qrvCBLxqKhdQm8pg%40mail.gmail.com.

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

<div dir=3D"ltr">I can easily think of a g() and h() that are not &quot;bad=
&quot; but are still order-dependent.=C2=A0 They might, for example, be con=
suming items from a stream, or writing items to one.<br><br>And as @Miro sa=
ys, we know f(g(), h()) is &quot;bad&quot; because we know it causes non-de=
terministic behavior.=C2=A0 Once order of evaluation is defined, depending =
on order will no longer be bad, and we can stop warning people about it.<br=
><br>And as for overloaded operator&amp;&amp;, that is another terrible err=
or in the language design.=C2=A0 The way to fix it, as I have suggested (bu=
t not formally proposed) before, is to define a new form of function parame=
ter tagged with [], e.g., void f([] int x), which would cause the argument =
expression to be wrapped in a special form of lambda that is evaluated with=
in the function only if the function chooses to evaluate the parameter. =C2=
=A0(And we need a &quot;special form&quot; of lambda because each regular l=
ambda is a different type, so a function taking lambda parameters needs to =
be a template; maybe a std::function could be invisibly interposed...=C2=A0=
 Oh, C++.=C2=A0 You break my heart.)</div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On Sun, Mar 6, 2016 at 7:38 PM, Miro Knejp <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">mi=
ro.knejp@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"">Am 06.03.2016 um 23:20 schrieb Bo Persson:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 2016-03-06 18:45, Miro Knejp wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
So in order to manually sequence the expression<br>
f(g(), h())<br>
<br>
I have to write<br>
auto a =3D g();<br>
auto b =3D h();<br>
f(std::move(a), std::move(b))<br>
<br>
The compiler has more freedom with prvalues than it has with xvalues and<br=
>
I can tell from experience that people often forget std::move. Without<br>
the move a reviewer has to ask themselves &quot;is this copy deliberate or<=
br>
did they forget to move?&quot;. If evaluation order is well-defined then in=
<br>
the single-expression case there is nothing to forget and no ambiguity<br>
to worry about. One would do the correct and most efficient thing by<br>
default.<br>
<br>
</blockquote>
<br>
The order of calls is important in f(g(), h()), if calling h() affects the =
returned value of g(). The proposed fix is to have a left-to-right evaluati=
on.<br>
<br>
<br>
Someone else will no doubt use another function f2(h(), g()), which has the=
 same problem but will still be broken. So how do we fix that?<br>
</blockquote></span>
Then at least you have a consistently reproducible bug instead of the curre=
nt randomness.<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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/56DCCD99.7060808%40gmail.com" rel=3D"=
noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/56DCCD99.7060808%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaSyy7e0qSSvaoMyzyCR04tRODis3qr=
vCBLxqKhdQm8pg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaSyy7e0qSS=
vaoMyzyCR04tRODis3qrvCBLxqKhdQm8pg%40mail.gmail.com</a>.<br />

--001a11438a4e1329e4052d77b05f--

.

--089e01229aaa334d6b052d77c7cf
Content-Type: text/plain; charset=UTF-8

On 7 March 2016 at 10:09, Hyman Rosen <hyman.rosen@gmail.com> wrote:

>
> And as for overloaded operator&&, that is another terrible error in the
> language design.  The way to fix it, as I have suggested (but not formally
> proposed) before, is to define a new form of function parameter tagged with
> [], e.g., void f([] int x), which would cause the argument expression to be
> wrapped in a special form of lambda that is evaluated within the function
> only if the function chooses to evaluate the parameter.
>

IOW, you want a special form of function parameter to indicate out of order
evaluation, if it is evaluated at all.

So, out of order evaluation is bad when you don't want it, but good when
you do want it???
--
 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%2BNKHF3HQ0mWcBtz40BEBa2EmZMc%2BKJPbBMTNOSTJB%3DJyw%40mail.gmail.com.

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

<div dir=3D"ltr">On 7 March 2016 at 10:09, 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>&gt;</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"><br>And as for =
overloaded operator&amp;&amp;, that is another terrible error in the langua=
ge design.=C2=A0 The way to fix it, as I have suggested (but not formally p=
roposed) before, is to define a new form of function parameter tagged with =
[], e.g., void f([] int x), which would cause the argument expression to be=
 wrapped in a special form of lambda that is evaluated within the function =
only if the function chooses to evaluate the parameter. </div></blockquote>=
<div><br></div><div>IOW, you want a special form of function parameter to i=
ndicate out of order evaluation, if it is evaluated at all.</div><div><br><=
/div><div>So, out of order evaluation is bad when you don&#39;t want it, bu=
t good when you do want it???</div></div>-- <br><div class=3D"gmail_signatu=
re"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot;=
 Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>&gt; =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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNKHF3HQ0mWcBtz40BEBa2EmZMc%2=
BKJPbBMTNOSTJB%3DJyw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNK=
HF3HQ0mWcBtz40BEBa2EmZMc%2BKJPbBMTNOSTJB%3DJyw%40mail.gmail.com</a>.<br />

--089e01229aaa334d6b052d77c7cf--

.

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

On Mon, Mar 7, 2016 at 11:15 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> So, out of order evaluation is bad when you don't want it, but good when
> you do want it???
>

C++ has three expression forms (&&, ||, ?:) in which some subexpressions
may remain unevaluated, and two of these may be overloaded but in a way
that does not preserve those evaluation semantics.  That is terribly bad.
If we want to have overloads that preserve the language semantics, and we
want overloads to be written in the form of function calls, then the
functions must be given control over whether and when their arguments are
evaluated.

Once such control is given, then functions could evaluate their functions
out of order if they chose to, but it *would* be a matter of choice;
presumably non-ltr order would be chosen only for good reason.  (Note that
aside from proper overloading of operator&& and operator&&, such a device
could also be used, for example, to create a "pick function" - pick(i,
expr0, expr1, ..., exprn) - which returns its i'th parameter, evaluating
only its i'th argument.)

Note, however, that while this allows function arguments to be evaluated in
non-ltr fashion if the function so chooses, this evaluation is not subject
to arbitrary reordering by different versions of the compiler.  Calls to
such functions will work consistently, with or without optimization, and
regardless of platform.

--
You received this message because you are 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/CAHSYqdYFfcdXt5Lfsu8XPyigZeoeZV7pt4Qno5FW7QggcM-z2Q%40mail.gmail.com.

--001a1143f36cf6a2cd052d7815c1
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, Mar 7, 2016 at 11:15 AM, Nevin Liber <span dir=3D"ltr">&lt;<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"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><div>So, out of order evalu=
ation is bad when you don&#39;t want it, but good when you do want it???</d=
iv></div></div></div></blockquote><div>=C2=A0</div><div>C++ has three expre=
ssion forms (&amp;&amp;, ||, ?:) in which some subexpressions may remain un=
evaluated, and two of these may be overloaded but in a way that does not pr=
eserve those evaluation semantics.=C2=A0 That is terribly bad.=C2=A0 If we =
want to have overloads that preserve the language semantics, and we want ov=
erloads to be written in the form of function calls, then the functions mus=
t be given control over whether and when their arguments are evaluated.<br>=
<br>Once such control is given, then functions could evaluate their functio=
ns out of order if they chose to, but it *would* be a matter of choice; pre=
sumably non-ltr order would be chosen only for good reason. =C2=A0(Note tha=
t aside from proper overloading of operator&amp;&amp; and operator&amp;&amp=
;, such a device could also be used, for example, to create a &quot;pick fu=
nction&quot; - pick(i, expr0, expr1, ..., exprn) - which returns its i&#39;=
th parameter, evaluating only its i&#39;th argument.)<br><br>Note, however,=
 that while this allows function arguments to be evaluated in non-ltr fashi=
on if the function so chooses, this evaluation is not subject to arbitrary =
reordering by different versions of the compiler.=C2=A0 Calls to such funct=
ions will work consistently, with or without optimization, and regardless o=
f platform.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYFfcdXt5Lfsu8XPyigZeoeZV7pt4Qn=
o5FW7QggcM-z2Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYFfcdXt5Lf=
su8XPyigZeoeZV7pt4Qno5FW7QggcM-z2Q%40mail.gmail.com</a>.<br />

--001a1143f36cf6a2cd052d7815c1--

.

--089e01229aaa87f807052d783eb5
Content-Type: text/plain; charset=UTF-8

On 7 March 2016 at 10:37, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> Once such control is given, then functions could evaluate their functions
> out of order if they chose to,
>

Who does the choosing:  caller, callee or both?


> but it *would* be a matter of choice; presumably non-ltr order would be
> chosen only for good reason.
>

There is a good reason now (optimization of correct code).  Just because
you personally don't agree with it doesn't change that.



> (Note that aside from proper overloading of operator&& and operator&&,
> such a device could also be used, for example, to create a "pick function"
> - pick(i, expr0, expr1, ..., exprn) - which returns its i'th parameter,
> evaluating only its i'th argument.)
>

Which would break pick(g(), h()) from strictly calling g() before h().


> Note, however, that while this allows function arguments to be evaluated
> in non-ltr fashion if the function so chooses, this evaluation is not
> subject to arbitrary reordering by different versions of the compiler.
> Calls to such functions will work consistently, with or without
> optimization, and regardless of platform.
>

Which makes code extremely brittle because it becomes dependent on
implementation details of pick.

It is exactly the same problem, other than you want this and don't want
ub.  Either way, I'd have to tell users "there be dragons; don't go there".
--
 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%2BPajXK_dt4TsmSrF9y%3Dn5gfOqWn8tJOVdmV%2B4x%3DQS3ctQ%40mail.gmail.com.

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

<div dir=3D"ltr">On 7 March 2016 at 10:37, 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>&gt;</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>Once such control is given, the=
n functions could evaluate their functions out of order if they chose to,</=
div></div></div></div></blockquote><div><br></div><div>Who does the choosin=
g: =C2=A0caller, callee or both?</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 class=3D"gmail_extra"><div class=3D"gmail_=
quote"><div> but it *would* be a matter of choice; presumably non-ltr order=
 would be chosen only for good reason. =C2=A0</div></div></div></div></bloc=
kquote><div><br></div><div>There is a good reason now (optimization of corr=
ect code).=C2=A0 Just because you personally don&#39;t agree with it doesn&=
#39;t change that.</div><div><br></div><div>=C2=A0</div><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>(Note that aside from proper overloading of operator&amp;&am=
p; and operator&amp;&amp;, such a device could also be used, for example, t=
o create a &quot;pick function&quot; - pick(i, expr0, expr1, ..., exprn) - =
which returns its i&#39;th parameter, evaluating only its i&#39;th argument=
..)<br></div></div></div></div></blockquote><div><br></div><div>Which would =
break pick(g(), h()) from strictly calling g() before h().</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div>Note, however, that while this allows=
 function arguments to be evaluated in non-ltr fashion if the function so c=
hooses, this evaluation is not subject to arbitrary reordering by different=
 versions of the compiler.=C2=A0 Calls to such functions will work consiste=
ntly, with or without optimization, and regardless of platform.</div></div>=
</div></div></blockquote><div><br></div><div>Which makes code extremely bri=
ttle because it becomes dependent on implementation details of pick.</div><=
div><br></div><div>It is exactly the same problem, other than you want this=
 and don&#39;t want ub.=C2=A0 Either way, I&#39;d have to tell users &quot;=
there be dragons; don&#39;t go there&quot;.</div></div>-- <br><div class=3D=
"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &=
quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.=
com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPajXK_dt4TsmSrF9y%3Dn5gfOqWn=
8tJOVdmV%2B4x%3DQS3ctQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
PajXK_dt4TsmSrF9y%3Dn5gfOqWn8tJOVdmV%2B4x%3DQS3ctQ%40mail.gmail.com</a>.<br=
 />

--089e01229aaa87f807052d783eb5--

.

On 2016-03-04 02:25, Michi Henning wrote:
> I would have thought that, in many cases, the compiler could still re-order under an as-if rule.

Only if the code is inline. This is the problem I raised before; we lack
a standard-conforming way to describe side effects (or more to the
point, lack thereof).

BTW, P0145R1 was forwarded to Core at Jacksonville. I guess they aren't
done with it as I don't recall it being one of the plenary motions.
(Looking at the notes, it appears to have been kicked back for wording
fixes.)

Anyone that feels very strongly about this had better write a paper
ASAP, and probably needs to show up at Oulu to present it...

--
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/nbke3g%24ec7%241%40ger.gmane.org.

.

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

On Mon, Mar 7, 2016 at 11:48 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 7 March 2016 at 10:37, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>
>> Once such control is given, then functions could evaluate their functions
>> out of order if they chose to,
>>
>
> Who does the choosing:  caller, callee or both?
>

The called function.



> but it *would* be a matter of choice; presumably non-ltr order would be
>> chosen only for good reason.
>>
>
> There is a good reason now (optimization of correct code).  Just because
> you personally don't agree with it doesn't change that.
>

Optimization is not a meaningful reason for the order of evaluation chosen
by a function with by-name parameters (that's what it was called in Algol
60), because optimization is something applied by the compiler, not by the
author of the code.  A function with by-name parameters will generally have
documentation describing the circumstances under which arguments will be
evaluated, and there may be circumstances aside from sheer cussedness when
non-ltr could be chosen.


> (Note that aside from proper overloading of operator&& and operator&&,
>> such a device could also be used, for example, to create a "pick function"
>> - pick(i, expr0, expr1, ..., exprn) - which returns its i'th parameter,
>> evaluating only its i'th argument.)
>>
>
> Which would break pick(g(), h()) from strictly calling g() before h().
>

I don't understand what you mean.  'pick()' would have an ordinary integer
first parameter and then a pack of by-name parameters.  It would use the
value of the first parameter to evaluate and return one and only one of the
others - the rest of the arguments would be unevaluated.  WIth by-name
parameters you could certainly choose to create very weird evaluation
orders, but that would be an odd choice to make without good reason.

>
>
>> Note, however, that while this allows function arguments to be evaluated
>> in non-ltr fashion if the function so chooses, this evaluation is not
>> subject to arbitrary reordering by different versions of the compiler.
>> Calls to such functions will work consistently, with or without
>> optimization, and regardless of platform.
>>
>
> Which makes code extremely brittle because it becomes dependent on
> implementation details of pick.
>

But far less brittle than code which relies on the implementation details
of the compiler.  Once by-name parameters are available, programmers will
use them to achieve effects that are now not possible or not easy, and will
document accordingly.  The evaluation properties of pick() are not its
implementation details, they are its documented interface.


> It is exactly the same problem, other than you want this and don't want
> ub.  Either way, I'd have to tell users "there be dragons; don't go there".
>

You would be 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/CAHSYqdb-APq6pmm3-OU3U3CDvn-SLsRt8EK0HCJV%3DCKC94RU%3Dg%40mail.gmail.com.

--001a11438a4e05105f052d79a87d
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, Mar 7, 2016 at 11:48 AM, Nevin Liber <span dir=3D"ltr">&lt;<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 7 March 2016 at 10:37, Hyman Rosen <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.co=
m</a>&gt;</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"><div>Once such con=
trol is given, then functions could evaluate their functions out of order i=
f they chose to,</div></div></div></div></blockquote><div><br></div></span>=
<div>Who does the choosing: =C2=A0caller, callee or both?</div></div></div>=
</div></blockquote><div><br>The called function.<br><br>=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 class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div> but i=
t *would* be a matter of choice; presumably non-ltr order would be chosen o=
nly for good reason. =C2=A0</div></div></div></div></blockquote><div><br></=
div></span><div>There is a good reason now (optimization of correct code).=
=C2=A0 Just because you personally don&#39;t agree with it doesn&#39;t chan=
ge that.</div></div></div></div></blockquote><div><br>Optimization is not a=
 meaningful reason for the order of evaluation chosen by a function with by=
-name parameters (that&#39;s what it was called in Algol 60), because optim=
ization is something applied by the compiler, not by the author of the code=
..=C2=A0 A function with by-name parameters will generally have documentatio=
n describing the circumstances under which arguments will be evaluated, and=
 there may be circumstances aside from sheer cussedness when non-ltr could =
be chosen.<br>=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"><span class=3D""><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div>(Note that aside from proper overloading of oper=
ator&amp;&amp; and operator&amp;&amp;, such a device could also be used, fo=
r example, to create a &quot;pick function&quot; - pick(i, expr0, expr1, ..=
.., exprn) - which returns its i&#39;th parameter, evaluating only its i&#39=
;th argument.)<br></div></div></div></div></blockquote><div><br></div></spa=
n><div>Which would break pick(g(), h()) from strictly calling g() before h(=
).</div></div></div></div></blockquote><div><br>I don&#39;t understand what=
 you mean. =C2=A0&#39;pick()&#39; would have an ordinary integer first para=
meter and then a pack of by-name parameters.=C2=A0 It would use the value o=
f the first parameter to evaluate and return one and only one of the others=
 - the rest of the arguments would be unevaluated.=C2=A0 WIth by-name param=
eters you could certainly choose to create very weird evaluation orders, bu=
t that would be an odd choice to make without good reason.=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><span class=3D""><div>=C2=A0</div><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>Note, however, that while this allows function arguments to =
be evaluated in non-ltr fashion if the function so chooses, this evaluation=
 is not subject to arbitrary reordering by different versions of the compil=
er.=C2=A0 Calls to such functions will work consistently, with or without o=
ptimization, and regardless of platform.</div></div></div></div></blockquot=
e><div><br></div></span><div>Which makes code extremely brittle because it =
becomes dependent on implementation details of pick.</div></div></div></div=
></blockquote><div><br>But far less brittle than code which relies on the i=
mplementation details of the compiler.=C2=A0 Once by-name parameters are av=
ailable, programmers will use them to achieve effects that are now not poss=
ible or not easy, and will document accordingly.=C2=A0 The evaluation prope=
rties of pick() are not its implementation details, they are its documented=
 interface.<br>=C2=A0</div><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>It is exactly th=
e same problem, other than you want this and don&#39;t want ub.=C2=A0 Eithe=
r way, I&#39;d have to tell users &quot;there be dragons; don&#39;t go ther=
e&quot;.</div></div></div></div></blockquote><div><br>You would be wrong.=
=C2=A0</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdb-APq6pmm3-OU3U3CDvn-SLsRt8EK0=
HCJV%3DCKC94RU%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdb-APq6=
pmm3-OU3U3CDvn-SLsRt8EK0HCJV%3DCKC94RU%3Dg%40mail.gmail.com</a>.<br />

--001a11438a4e05105f052d79a87d--

.

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

What worries me, given that the motivating argument is (in large part) that
we sometimes face opaque 3rd-party libraries that perform side-effects
without our knowledge (if we're using our own code, I assume we're
responsible for it and I suppose we know about the presence of absence of
side-effects; there's a point where the programmers have a responsibility
in their own craft):


   - Today: some colleague writes f(g(), h()), there are side-effects to
   either g() or h() (if you use an opaque 3rd-party library, be safe and
   assume there are such side-effects), the solution is simple: don't do it=
,
   it's broken, standard says so, been like that since forever. It's an eas=
y
   rule to learn and remember
   - With LTR or RTL mandated: some colleague writes f(g(), h()), there are
   side-effects to either g() or h(), a bug occurs, the code (awful as it
   might seem to some, including me as of this writing) is valid and we hav=
e a
   nice debugging session inspecting the doings of g() and h() and whatever
   they call (fun stuff with a 3rd-opaque library). Of course, one could ha=
ve
   called g() and h() before in a reasonable order, but that was already th=
e
   way to do things before the change. If it's valid to write code that
   depends on this ordering, then we have to know more to make sure things
   work the way we want them to

More simply put:

   - Today: the rule is known, evaluation order is undefined so don't do
   anything that depends on it. It's actually simple in my eyes: you need
   things to be ordered, you know what to do; if you don't know in which or=
der
   g() and h() have to be done, defining an ordering in the standard won't
   help you anyway
   - Fixed ordering will gain you consistent working / consistent crashing,
   which will force you to investigate anyway to know why it works (remembe=
r:
   the argument provided is we're using 3rd-party tools with bad documentat=
ion
   and everything, so we don't necessarily know if it really works) or why =
it
   crashes. After: the rule is known, evaluation order is defined, so shoul=
d
   anyone depend on it, bugs will require delving into the internals of the
   opaque code and have fun. Unless the coding guidelines say =C2=ABdon't d=
o such
   things=C2=BB, but they already did before the change :)


To be honest, as much as I understand the request for consistent behavior,
it seems to me that we should not roll dice with the software we write. The
investigation as to the presence or absence of side-effects has to be done
with or without ordering; it's just the job we're paid to do. Even in a
defined-ordering, this investigation has to be done to ensure software is
correct. The thing ordering really introduces in this case (or so it seems
to me) is potential reliance on the ordering. This leads to idioms, which
some have said they agreed with (they might be right; said idioms seem
terrible to me right now but I might be old school and I'm willing to
accept that, as it's not a scientific argument :) ). What I do understand
from all this is that the effort to understand what programmers are doing
when writing f(g(), h()) does not go away with LTR or RTL ordering: if the
chosen ordering conflicts with what the programmer planned, the situation
still needs to be investigated, and if things work =C2=ABas expected=C2=BB,
investigation still needs to be performed to avoid works-by-accident
situations. The effort is as needed with or without ordering; there's no
getting out of doing the work we're paid to do.

For this reason, as much as I hear and understand the pleas for ordering in
this case (as there are many other cases that don't bug me at all :) ),
this one leaves me unconvinced. The upsides are slim, the downsides seem
important.

For those who claim the idioms that would stem from ordering of g() and h()
in f(g(), h()) would be a =C2=ABgood thing=C2=BB(TM :) ), maybe instructive=
 examples
would help understand your point of view?

Cheers!


2016-03-07 13:29 GMT-05:00 Hyman Rosen <hyman.rosen@gmail.com>:

> On Mon, Mar 7, 2016 at 11:48 AM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>
>> On 7 March 2016 at 10:37, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>>
>>> Once such control is given, then functions could evaluate their
>>> functions out of order if they chose to,
>>>
>>
>> Who does the choosing:  caller, callee or both?
>>
>
> The called function.
>
>
>
>> but it *would* be a matter of choice; presumably non-ltr order would be
>>> chosen only for good reason.
>>>
>>
>> There is a good reason now (optimization of correct code).  Just because
>> you personally don't agree with it doesn't change that.
>>
>
> Optimization is not a meaningful reason for the order of evaluation chose=
n
> by a function with by-name parameters (that's what it was called in Algol
> 60), because optimization is something applied by the compiler, not by th=
e
> author of the code.  A function with by-name parameters will generally ha=
ve
> documentation describing the circumstances under which arguments will be
> evaluated, and there may be circumstances aside from sheer cussedness whe=
n
> non-ltr could be chosen.
>
>
>> (Note that aside from proper overloading of operator&& and operator&&,
>>> such a device could also be used, for example, to create a "pick functi=
on"
>>> - pick(i, expr0, expr1, ..., exprn) - which returns its i'th parameter,
>>> evaluating only its i'th argument.)
>>>
>>
>> Which would break pick(g(), h()) from strictly calling g() before h().
>>
>
> I don't understand what you mean.  'pick()' would have an ordinary intege=
r
> first parameter and then a pack of by-name parameters.  It would use the
> value of the first parameter to evaluate and return one and only one of t=
he
> others - the rest of the arguments would be unevaluated.  WIth by-name
> parameters you could certainly choose to create very weird evaluation
> orders, but that would be an odd choice to make without good reason.
>
>>
>>
>>> Note, however, that while this allows function arguments to be evaluate=
d
>>> in non-ltr fashion if the function so chooses, this evaluation is not
>>> subject to arbitrary reordering by different versions of the compiler.
>>> Calls to such functions will work consistently, with or without
>>> optimization, and regardless of platform.
>>>
>>
>> Which makes code extremely brittle because it becomes dependent on
>> implementation details of pick.
>>
>
> But far less brittle than code which relies on the implementation details
> of the compiler.  Once by-name parameters are available, programmers will
> use them to achieve effects that are now not possible or not easy, and wi=
ll
> document accordingly.  The evaluation properties of pick() are not its
> implementation details, they are its documented interface.
>
>
>> It is exactly the same problem, other than you want this and don't want
>> ub.  Either way, I'd have to tell users "there be dragons; don't go ther=
e".
>>
>
> You would be 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/CAHSYqdb-APq=
6pmm3-OU3U3CDvn-SLsRt8EK0HCJV%3DCKC94RU%3Dg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdb-AP=
q6pmm3-OU3U3CDvn-SLsRt8EK0HCJV%3DCKC94RU%3Dg%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/CAKiZDp3b0f%2Br5SHars7Vw3C9UG6C3J%3Dd5uxTk6DS5dU=
xdhc%3D6A%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div><div><div><div><div><div>What worries me, given =
that the motivating argument is (in large part) that we sometimes face opaq=
ue 3rd-party libraries that perform side-effects without our knowledge (if =
we&#39;re using our own code, I assume we&#39;re responsible for it and I s=
uppose we know about the presence of absence of side-effects; there&#39;s a=
 point where the programmers have a responsibility in their own craft):<br>=
<br></div><ul><li>Today: some colleague writes f(g(), h()), there are side-=
effects to either g() or h() (if you use an opaque 3rd-party library, be sa=
fe and assume there are such side-effects), the solution is simple: don&#39=
;t do it, it&#39;s broken, standard says so, been like that since forever. =
It&#39;s an easy rule to learn and remember<br></li><li>With LTR or RTL man=
dated: some colleague writes f(g(), h()), there are side-effects to either =
g() or h(), a bug occurs, the code (awful as it might seem to some, includi=
ng me as of this writing) is valid and we have a nice debugging session ins=
pecting the doings of g() and h() and whatever they call (fun stuff with a =
3rd-opaque library). Of course, one could have called g() and h() before in=
 a reasonable order, but that was already the way to do things before the c=
hange. If it&#39;s valid to write code that depends on this ordering, then =
we have to know more to make sure things work the way we want them to</li><=
/ul><p>More simply put:<br></p><ul><li>Today: the rule is known, evaluation=
 order is undefined so don&#39;t do anything that depends on it. It&#39;s a=
ctually simple in my eyes: you need things to be ordered, you know what to =
do; if you don&#39;t know in which order g() and h() have to be done, defin=
ing an ordering in the standard won&#39;t help you anyway</li><li>Fixed ord=
ering will gain you consistent working / consistent crashing, which will fo=
rce you to investigate anyway to know why it works (remember: the argument =
provided is we&#39;re using 3rd-party tools with bad documentation and ever=
ything, so we don&#39;t necessarily know if it really works) or why it cras=
hes. After: the rule is known, evaluation order is defined, so should anyon=
e depend on it, bugs will require delving into the internals of the opaque =
code and have fun. Unless the coding guidelines say =C2=ABdon&#39;t do such=
 things=C2=BB, but they already did before the change :)<br></li></ul></div=
></div></div><br></div>To be honest, as much as I understand the request fo=
r consistent behavior, it seems to me that we should not roll dice with the=
 software we write. The investigation as to the presence or absence of side=
-effects has to be done with or without ordering; it&#39;s just the job we&=
#39;re paid to do. Even in a defined-ordering, this investigation has to be=
 done to ensure software is correct. The thing ordering really introduces i=
n this case (or so it seems to me) is potential reliance on the ordering. T=
his leads to idioms, which some have said they agreed with (they might be r=
ight; said idioms seem terrible to me right now but I might be old school a=
nd I&#39;m willing to accept that, as it&#39;s not a scientific argument :)=
 ). What I do understand from all this is that the effort to understand wha=
t programmers are doing when writing f(g(), h()) does not go away with LTR =
or RTL ordering: if the chosen ordering conflicts with what the programmer =
planned, the situation still needs to be investigated, and if things work =
=C2=ABas expected=C2=BB, investigation still needs to be performed to avoid=
 works-by-accident situations. The effort is as needed with or without orde=
ring; there&#39;s no getting out of doing the work we&#39;re paid to do.<br=
><br></div>For this reason, as much as I hear and understand the pleas for =
ordering in this case (as there are many other cases that don&#39;t bug me =
at all :) ), this one leaves me unconvinced. The upsides are slim, the down=
sides seem important.<br><br></div>For those who claim the idioms that woul=
d stem from ordering of g() and h() in f(g(), h()) would be a =C2=ABgood th=
ing=C2=BB(TM :) ), maybe instructive examples would help understand your po=
int of view?<br><div><div><div><br><div><div><div>Cheers!<br></div><div><br=
></div></div></div></div></div></div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">2016-03-07 13:29 GMT-05:00 Hyman Rosen <span dir=
=3D"ltr">&lt;<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hym=
an.rosen@gmail.com</a>&gt;</span>:<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 class=3D"gmail_extra"><div class=3D"gmail_quote"><span clas=
s=3D"">On Mon, Mar 7, 2016 at 11:48 AM, Nevin Liber <span dir=3D"ltr">&lt;<=
a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlo=
rd.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>On 7 March 2016 at 10:37, Hyman Rosen <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.co=
m</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><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 cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><div>Once such control is giv=
en, then functions could evaluate their functions out of order if they chos=
e to,</div></div></div></div></blockquote><div><br></div></span><div>Who do=
es the choosing: =C2=A0caller, callee or both?</div></div></div></div></blo=
ckquote></span><div><br>The called function.<br><br>=C2=A0</div><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><span><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"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div> but=
 it *would* be a matter of choice; presumably non-ltr order would be chosen=
 only for good reason. =C2=A0</div></div></div></div></blockquote><div><br>=
</div></span><div>There is a good reason now (optimization of correct code)=
..=C2=A0 Just because you personally don&#39;t agree with it doesn&#39;t cha=
nge that.</div></div></div></div></blockquote></span><div><br>Optimization =
is not a meaningful reason for the order of evaluation chosen by a function=
 with by-name parameters (that&#39;s what it was called in Algol 60), becau=
se optimization is something applied by the compiler, not by the author of =
the code.=C2=A0 A function with by-name parameters will generally have docu=
mentation describing the circumstances under which arguments will be evalua=
ted, and there may be circumstances aside from sheer cussedness when non-lt=
r could be chosen.<br>=C2=A0</div><span class=3D""><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 class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><span><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"><div>(Note that aside from proper overl=
oading of operator&amp;&amp; and operator&amp;&amp;, such a device could al=
so be used, for example, to create a &quot;pick function&quot; - pick(i, ex=
pr0, expr1, ..., exprn) - which returns its i&#39;th parameter, evaluating =
only its i&#39;th argument.)<br></div></div></div></div></blockquote><div><=
br></div></span><div>Which would break pick(g(), h()) from strictly calling=
 g() before h().</div></div></div></div></blockquote></span><div><br>I don&=
#39;t understand what you mean. =C2=A0&#39;pick()&#39; would have an ordina=
ry integer first parameter and then a pack of by-name parameters.=C2=A0 It =
would use the value of the first parameter to evaluate and return one and o=
nly one of the others - the rest of the arguments would be unevaluated.=C2=
=A0 WIth by-name parameters you could certainly choose to create very weird=
 evaluation orders, but that would be an odd choice to make without good re=
ason.=C2=A0</div><span class=3D""><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><div>=
=C2=A0</div><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>Note, however, that while this =
allows function arguments to be evaluated in non-ltr fashion if the functio=
n so chooses, this evaluation is not subject to arbitrary reordering by dif=
ferent versions of the compiler.=C2=A0 Calls to such functions will work co=
nsistently, with or without optimization, and regardless of platform.</div>=
</div></div></div></blockquote><div><br></div></span><div>Which makes code =
extremely brittle because it becomes dependent on implementation details of=
 pick.</div></div></div></div></blockquote></span><div><br>But far less bri=
ttle than code which relies on the implementation details of the compiler.=
=C2=A0 Once by-name parameters are available, programmers will use them to =
achieve effects that are now not possible or not easy, and will document ac=
cordingly.=C2=A0 The evaluation properties of pick() are not its implementa=
tion details, they are its documented interface.<br>=C2=A0</div><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div>It is exactly the same problem, other=
 than you want this and don&#39;t want ub.=C2=A0 Either way, I&#39;d have t=
o tell users &quot;there be dragons; don&#39;t go there&quot;.</div></div><=
/div></div></blockquote></span><div><br>You would be wrong.=C2=A0</div></di=
v><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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAHSYqdb-APq6pmm3-OU3U3CDvn-SLsRt8EK0=
HCJV%3DCKC94RU%3Dg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAHSYqdb-APq6pmm3-OU3U3CDvn-SLsRt8EK0HCJV%3DCKC94RU%3Dg%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3b0f%2Br5SHars7Vw3C9UG6C3J%3Dd=
5uxTk6DS5dUxdhc%3D6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3b0f=
%2Br5SHars7Vw3C9UG6C3J%3Dd5uxTk6DS5dUxdhc%3D6A%40mail.gmail.com</a>.<br />

--001a11457788463b1e052d8029b3--

.

------=_Part_2336_1526555041.1457429673320
Content-Type: multipart/alternative;
 boundary="----=_Part_2337_1563134969.1457429673321"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=883=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC+=
8=E4=B8=8B=E5=8D=8810:49:52=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 03.03.2016 um 03:37 schrieb 'Edward Catmur' via ISO C++ Standard -=20
> Future Proposals:
>
>
> On 1 Mar 2016 04:10, "Hyman Rosen" <hyman...@gmail.com <javascript:>>=20
> wrote:
> >
> > On Mon, Feb 29, 2016 at 2:56 PM, Nevin Liber < <javascript:>
> ne...@cplusplusguy.com <javascript:>> wrote:
> >>
> >> Constantly repeating the solution you want while ignoring all other=20
> concerns is not a way to build consensus, IMHO.
> >
> >
> > Sometimes the only way to build consensus is to wear down the other=20
> side.  Having a real-world example is a way to do that.
> >
>
> An anecdote does not constitute a real-world example.=20
>
> I invited you to expand on your anecdote (I'm assuming you can't share=20
> full details) and you chose to interpret that as blaming the victim. Your=
=20
> arguments carry less weight if you cannot demonstrate that you have at=20
> least considered other options: deprecating older APIs in favor of=20
> command-query separation, requesting warning diagnostics for code dependi=
ng=20
> on evaluation order, or requesting vendor compatibility modes (-fltr and=
=20
> -frtl, say, along the lines of -fwrapv, or equivalent pragmas for=20
> finer-grained control).
>
> If you can't or won't change any of your code, I can't see why -fltr=20
> shouldn't be a satisfactory option - and if it really is the superior=20
> choice, then in a few years everyone will be using it and mandating it ca=
n=20
> be considered.=20
>
> Can you really blame someone for writing "f(a(), b(), c())" ? That is the=
=20
> most natural thing to do in any programming language out there. From my=
=20
> experience it is the first thing people do intuitively when learning=20
> programming. They expect things to be evaluated from left to right, becau=
se=20
> that is the order they typed it in. And it always works. Except when it=
=20
> doesn't (but only in C/C++), and then they spend hours or days bug huntin=
g=20
> (good way to ruin the programming experience for freshmen). And then try=
=20
> explaining to them why sometimes it's OK, but sometimes it isn't (at a=20
> point at which they would unlikely understand the point of command-query=
=20
> separation) and why they can't do it the natural way but have to go ot of=
=20
> their way to work around this "stupid language" that they never want to=
=20
> touch again. Frustrations like this are why so few students come out of=
=20
> university and think C++ is great, why it is increasingly harder to find=
=20
> C++ developers. Of course one can't blame *only* the language. Some=20
> professors and curriculums simply suck but if the students do programming=
=20
> exercises on their own and run into issues like this it ruins the=20
> experience. And then I hear Bjarne saying C++ is novice friendly and I cr=
y=20
> a little on the inside.
>
> This evaluation issue is something that everyone gets bitten by at some=
=20
> point. But it's never a big gaping wound that stands out to every reviewe=
r.=20
> It's more like a venom bite, slowly working its way and suddenly your hea=
rt=20
> stops beating.
>

They deserve to be blamed because they do not care the meaning of the code=
=20
(which is not difficult at all) enough, as they should.
And I didn't get bitten because I never assume out-of-rule is "natural" for=
=20
use of an artificial language in any time. What true "natural" thing (if=20
any) for average educated users here is, as in math, f(a(), b(), c())=20
should be pure, thus any order of evaluations is irrelevant to get the=20
expected result. This is obviously ridiculous.
Not only C and C++ have such deliberated unspecified evaluation order of=20
expressions. It is clearly *intended*, *by design*, to prevent such=20
"natural" excuse to hide ignorance and to *do the right thing*=20
<https://en.wikipedia.org/wiki/Worse_is_better#The_MIT_approach>.


--=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/42023ee0-287c-437b-931a-c8c97e824483%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=883=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=8810:49:52=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 03.03.2016 um 03:37 schrieb &#39;Edward Catmur&#39; via ISO C++ Stan=
dard
    - Future Proposals:<br>
    <blockquote type=3D"cite">
      <p dir=3D"ltr"><br>
        On 1 Mar 2016 04:10, &quot;Hyman Rosen&quot; &lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"GVhB6wrCBAAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">hyman...@gmail.com</a>&=
gt;
        wrote:<br>
        &gt;<br>
        &gt; On Mon, Feb 29, 2016 at 2:56 PM, Nevin Liber &lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"GVhB6wrCBAAJ" rel=3D"=
nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" on=
click=3D"this.href=3D&#39;javascript:&#39;;return true;"></a><a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"GVhB6wrCBAAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onc=
lick=3D"this.href=3D&#39;javascript:&#39;;return true;">ne...@cplusplusguy.=
com</a>&gt;
        wrote:<br>
        &gt;&gt;<br>
        &gt;&gt; Constantly repeating the solution you want while
        ignoring all other concerns is not a way to build consensus,
        IMHO.<br>
        &gt;<br>
        &gt;<br>
        &gt; Sometimes the only way to build consensus is to wear down
        the other side.=C2=A0 Having a real-world example is a way to do
        that.<br>
        &gt;</p>
      <p dir=3D"ltr">An anecdote does not constitute a real-world example.
      </p>
      <p dir=3D"ltr">I invited you to expand on your anecdote (I&#39;m
        assuming you can&#39;t share full details) and you chose to
        interpret that as blaming the victim. Your arguments carry less
        weight if you cannot demonstrate that you have at least
        considered other options: deprecating older APIs in favor of
        command-query separation, requesting warning diagnostics for
        code depending on evaluation order, or requesting vendor
        compatibility modes (-fltr and -frtl, say, along the lines of
        -fwrapv, or equivalent pragmas for finer-grained control).</p>
      <p dir=3D"ltr">If you can&#39;t or won&#39;t change any of your code,=
 I
        can&#39;t see why -fltr shouldn&#39;t be a satisfactory option - an=
d if
        it really is the superior choice, then in a few years everyone
        will be using it and mandating it can be considered. </p>
    </blockquote>
    Can you really blame someone for writing &quot;f(a(), b(), c())&quot; ?=
 That
    is the most natural thing to do in any programming language out
    there. From my experience it is the first thing people do
    intuitively when learning programming. They expect things to be
    evaluated from left to right, because that is the order they typed
    it in. And it always works. Except when it doesn&#39;t (but only in
    C/C++), and then they spend hours or days bug hunting (good way to
    ruin the programming experience for freshmen). And then try
    explaining to them why sometimes it&#39;s OK, but sometimes it isn&#39;=
t (at
    a point at which they would unlikely understand the point of
    command-query separation) and why they can&#39;t do it the natural way
    but have to go ot of their way to work around this &quot;stupid languag=
e&quot;
    that they never want to touch again. Frustrations like this are why
    so few students come out of university and think C++ is great, why
    it is increasingly harder to find C++ developers. Of course one
    can&#39;t blame *only* the language. Some professors and curriculums
    simply suck but if the students do programming exercises on their
    own and run into issues like this it ruins the experience. And then
    I hear Bjarne saying C++ is novice friendly and I cry a little on
    the inside.<br>
    <br>
    This evaluation issue is something that everyone gets bitten by at
    some point. But it&#39;s never a big gaping wound that stands out to
    every reviewer. It&#39;s more like a venom bite, slowly working its way
    and suddenly your heart stops beating.<br></div></blockquote><div><br>T=
hey deserve to be blamed because they do not care the meaning of the code (=
which is not difficult at all) enough, as they should.<br>And I didn&#39;t =
get bitten because I never assume out-of-rule is &quot;natural&quot; for us=
e of an artificial language in any time. What true &quot;natural&quot; thin=
g (if any)  for average educated users here is, as in math, f(a(), b(), c()=
) should be pure, thus any order of evaluations is irrelevant to get the ex=
pected result. This is obviously ridiculous.<br>Not only C and C++ have suc=
h deliberated unspecified evaluation order of expressions. It is clearly <i=
>intended</i>, <i>by design</i>, to prevent such &quot;natural&quot; excuse=
 to hide ignorance and to <a href=3D"https://en.wikipedia.org/wiki/Worse_is=
_better#The_MIT_approach"><i>do the right thing</i></a>.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/42023ee0-287c-437b-931a-c8c97e824483%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/42023ee0-287c-437b-931a-c8c97e824483=
%40isocpp.org</a>.<br />

------=_Part_2337_1563134969.1457429673321--
------=_Part_2336_1526555041.1457429673320--

.

------=_Part_6922_1564114823.1457436493925
Content-Type: multipart/alternative;
 boundary="----=_Part_6923_1736588222.1457436493926"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+=
8=E4=B8=8A=E5=8D=882:10:06=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Mar 2, 2016 at 9:37 PM, 'Edward Catmur' via ISO C++ Standard -=20
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
> It's not satisfactory because our code runs on several different=20
> platforms, using several different compilers.  We would need all of them =
to=20
> support this option, and since we support legacy platforms (e.g., AIX and=
=20
> SunOS), that is difficult.=20
>

Left-to-right just does not work for legacy platforms where only old=20
versions of G++ are available.
Anyway, you are talking about the future of the language. To urge the=20
vendors support the legacy platforms with proposed changes may need more=20
effort.

If it were part of the standard, it would be more likely to show up=20
> everywhere.  And how could you possibly measure "better" in this context?=
 =20
> It's a change which will be almost entirely undetectable.  It's effect wi=
ll=20
> be to prevent people from writing code that accidentally works but actual=
ly=20
> has unspecified behavior.  It's like asking to measure the effects of=20
> having a guardian angel - how do you measure the number of accidents that=
=20
> never happen?
>
> Relying on specific order of evaluation is already the code "accidentally=
=20
works but actually has unspecified behavior". You are requiring turning=20
some code accidentally works to be no so accidentally, while turning some=
=20
other code in the opposite way. That is probably in vain.
=20

> But regardless, the point is that having unspecified order of evaluation=
=20
> is bad for the C++ language and bad for C++ programmers.
>
No further evidence. Sounds religious.
=20

> I'm not just searching for a way to immunize my code from this poor=20
> decision, I want this poor decision removed from the language so that no=
=20
> one needs to suffer from it.
>
=20
So this is not about your code. Specified-but-not-I-want is always poorer=
=20
than "unspecified". You have already failed to convince people who think=20
right-to-left is superior (if any). And you are actually requiring stricter=
=20
restrictions and more complicated rules (if not, show your wording). This=
=20
is direct offense to users who use the language to precisely (as possible)=
=20
express what they need without disruption from any strange belief they=20
don't have, also to the philosophy of "you don=E2=80=99t pay for what you d=
on=E2=80=99t=20
use" (though mainly mentally).

--=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/a669f39b-3838-4ef1-b84c-b3ec1faba9dc%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=882:10:06=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 Wed, Mar 2, 2016 at 9:37 PM, =
&#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"C76nNvjMBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-pr...@isocpp.org</a>&gt;</span> wrote:<br><br><div>It&#39;s not=
 satisfactory because our code runs on several different platforms, using s=
everal different compilers.=C2=A0 We would need all of them to support this=
 option, and since we support legacy platforms (e.g., AIX and SunOS), that =
is difficult. </div></div></div></div></blockquote><div><br>Left-to-right j=
ust does not work for legacy platforms where only old versions of G++ are a=
vailable.<br>Anyway, you are talking about the future of the language. To u=
rge the vendors support the legacy platforms with proposed changes may need=
 more effort.<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>If it were part of the s=
tandard, it would be more likely to show up everywhere.=C2=A0 And how could=
 you possibly measure &quot;better&quot; in this context?=C2=A0 It&#39;s a =
change which will be almost entirely undetectable.=C2=A0 It&#39;s effect wi=
ll be to prevent people from writing code that accidentally works but actua=
lly has unspecified behavior.=C2=A0 It&#39;s like asking to measure the eff=
ects of having a guardian angel - how do you measure the number of accident=
s that never happen?<br><br></div></div></div></div></blockquote><div>Relyi=
ng on specific order of evaluation is already the code &quot;accidentally w=
orks but actually has unspecified behavior&quot;. You are requiring turning=
 some code accidentally works to be no so accidentally, while turning some =
other code in the opposite way. That is probably in vain.<br>=C2=A0<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>But regardless, the point is that having unspecif=
ied order of evaluation is bad for the C++ language and bad for C++ program=
mers.</div></div></div></div></blockquote><div>No further evidence. Sounds =
religious.<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>I&#39;m not just searchin=
g for a way to immunize my code from this poor decision, I want this poor d=
ecision removed from the language so that no one needs to suffer from it.</=
div></div></div></div></blockquote><div>=C2=A0<br>So this is not about your=
 code. Specified-but-not-I-want is always poorer than &quot;unspecified&quo=
t;. You have already failed to convince people who think right-to-left is s=
uperior (if any). And you are actually requiring stricter restrictions and =
more complicated rules (if not, show your wording). This is direct offense =
to users who use the language to precisely (as possible) express what they =
need without disruption from any strange belief they don&#39;t have, also t=
o the philosophy of &quot;you don=E2=80=99t pay for what you don=E2=80=99t =
use&quot; (though mainly mentally).<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a669f39b-3838-4ef1-b84c-b3ec1faba9dc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a669f39b-3838-4ef1-b84c-b3ec1faba9dc=
%40isocpp.org</a>.<br />

------=_Part_6923_1736588222.1457436493926--
------=_Part_6922_1564114823.1457436493925--

.

------=_Part_6952_682046077.1457438413668
Content-Type: multipart/alternative;
 boundary="----=_Part_6953_924326143.1457438413669"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+=
8=E4=B8=8A=E5=8D=889:06:46=EF=BC=8CMichi Henning=E5=86=99=E9=81=93=EF=BC=9A
>
> They didn't forget. They seem to have deliberately left it unspecified.
>
> Source: https://www.eskimo.com/~scs/cclass/notes/sx7c.html
>
> quote: The moral is that writing code that depends on order of evaluation=
=20
> is a bad programming practice in any language. Naturally, it is necessary=
=20
> to know what things to avoid, but if you don't know *how* they are done=
=20
> on various machines, you won't be tempted to take advantage of a particul=
ar=20
> implementation.=20
>
>
> I just dug out my 1st edition copy of K&R and, yes, those words are indee=
d=20
> there (final para on page 50).
>
> To state that =E2=80=9Cwriting code that depends on order of evaluation i=
s bad=20
> programming practice in any language=E2=80=9D is to make a rather sweepin=
g=20
> statement, and one that is contradicted by many modern languages. In K&R=
=E2=80=99s=20
> defense, the statement was made almost 40 years ago.
>
> We use sequencing all the time. If I write
>
> a =3D b;
> c +=3D 2 * a;
>
> I=E2=80=99d be rather surprised if the compiler were to re-order these tw=
o=20
> statements.
>

Certainly not allowed. Semicolons has clear semantics to forbid this.
=20

> But, for some reason I can=E2=80=99t quite follow, doing the same thing f=
or=20
> expressions is considered bad, even though a complex expression is just a=
=20
> sequence of simple statements. Why anyone would deem it desirable for=20
> things to be evaluated in any order is beyond me, hypothetical compile-ti=
me=20
> optimizations notwithstanding.
>
> Things are just different for commas. It should be natural semicolons and=
=20
commas are different, because they look different. If you want sequenced=20
evaluation, use semicolons explicitly. This is clean, tidy and easy.

The true bad thing is, whether a comma indicates sequenced evaluation or=20
not is context-sensitive. It depends on whether it is an operator or not.=
=20
This syntactic inconsistency is stupid, since it confuse peoples a lot, and=
=20
the only usage is to overcome the fact of lacking of sequenced evaluation=
=20
constructs in clauses of some statements. This is the limitation of=20
standard C. Both expression statements and lambda expressions can work=20
around it nicely, but as a consequence of that random design, (possibly=20
insanely overloaded) "operator," remains painful in C++. Forcing=20
left-to-right evaluation on function calls would eliminate the=20
inconsistency between overloaded and builtin "operator,", however, also=20
make the whole design of language uglier. To be pragmatic, I don't care=20
about it too much, but it indeed screw up the process of reasoning a lot,=
=20
which should be desperately needed by people here (to avoid turning the=20
language into totally unsustainable mess).

(On the other hand, "statement" itself is a kind of shortsighted artifact,=
=20
as a result of poor programing language theory practice in some "modern"=20
cases. But this is another story.)

The second rationale strikes me as completely back to front:
>
> =E2=80=9CIf you don=E2=80=99t know how they are done on various machines,=
 you won=E2=80=99t be=20
> tempted to take advantage of a particular implementation.=E2=80=9D
>
> The problem isn=E2=80=99t that people are tempted to take advantage. The =
problem=20
> is that they write something, test it, find that it works, and move on. A=
ll=20
> the while being blissfully ignorant that the working code, as a matter of=
=20
> fact, has undefined behavior.
>
> But, hey, this is C++, right? If we can make it more complicated, let=E2=
=80=99s!
>
> My faith in humanity is lost forever.
>
>
> I=E2=80=99m not quite as bleak as that, but close. After twenty-five year=
s of=20
> writing C++ on a daily basis, I am still spending a large part of my=20
> programming effort watching myself over my own shoulder, just to avoid=20
> shooting myself in the foot with something silly, such as forgetting to=
=20
> disable a copy constructor or accidentally relying on undefined evaluatio=
n=20
> order. It=E2=80=99s tedious, to say the least.
>
> And, after twenty-five years, I=E2=80=99m still unable to say that C++ is=
 easy. It=20
> isn=E2=80=99t, period. If performance doesn=E2=80=99t matter, give me Jav=
a or C# any day.=20
> (And, no, I=E2=80=99m not a Java weenie. But Java *is* easy, certainly wh=
en=20
> compared to C++.)
>
> Do you really know who are trying to make it more complicated? And how?

C++ isn't easy. True. But it could have been easier.

And the core language of Java is actually more complicated than C++. See=20
the Java 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/6934b9a2-8bb3-4d5d-a4fe-30861ea993fd%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=889:06:46=EF=BC=8CMichi Henning=
=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 style=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><div><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div>They didn&#39;t forget. The=
y seem to have deliberately left it unspecified.</div><div><br></div><div>S=
ource: <a href=3D"https://www.eskimo.com/~scs/cclass/notes/sx7c.html" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.g=
oogle.com/url?q\75https%3A%2F%2Fwww.eskimo.com%2F~scs%2Fcclass%2Fnotes%2Fsx=
7c.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFNt-xFm-Lk2Woh-HktQAS-ncTJ2Q&#39=
;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75=
https%3A%2F%2Fwww.eskimo.com%2F~scs%2Fcclass%2Fnotes%2Fsx7c.html\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNFNt-xFm-Lk2Woh-HktQAS-ncTJ2Q&#39;;return true;">ht=
tps://www.eskimo.com/~scs/<wbr>cclass/notes/sx7c.html</a></div><div><br></d=
iv><div>quote:=C2=A0<font color=3D"#ff0000"><span style=3D"font-family:&#39=
;Times New Roman&#39;;font-size:inherit">The moral is that writing code tha=
t depends on order of evaluation is a bad programming practice in any langu=
age. Naturally, it is necessary to know what things to avoid, but if you do=
n&#39;t know=C2=A0</span><i style=3D"font-family:&#39;Times New Roman&#39;;=
font-size:inherit">how</i><span style=3D"font-family:&#39;Times New Roman&#=
39;;font-size:inherit">=C2=A0they are done on various machines, you won&#39=
;t be tempted to take advantage of a particular implementation.</span>=C2=
=A0</font></div></div></div></div></div></blockquote><div><br></div>I just =
dug out my 1st edition copy of K&amp;R and, yes, those words are indeed the=
re (final para on page 50).</div><div><br></div><div>To state that =E2=80=
=9Cwriting code that depends on order of evaluation is bad programming prac=
tice in any language=E2=80=9D is to make a rather sweeping statement, and o=
ne that is contradicted by many modern languages. In K&amp;R=E2=80=99s defe=
nse, the statement was made almost 40 years ago.</div><div><br></div><div>W=
e use sequencing all the time. If I write</div><div><br></div><div>a =3D b;=
</div><div>c +=3D 2 * a;</div><div><br></div><div>I=E2=80=99d be rather sur=
prised if the compiler were to re-order these two statements.</div></div></=
blockquote><div><br>Certainly not allowed. Semicolons has clear semantics t=
o forbid this.<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 style=3D"word-wrap:break-word"><div>But, for some reason I can=
=E2=80=99t quite follow, doing the same thing for expressions is considered=
 bad, even though a complex expression is just a sequence of simple stateme=
nts. Why anyone would deem it desirable for things to be evaluated in any o=
rder is beyond me, hypothetical compile-time optimizations notwithstanding.=
</div><div><br></div></div></blockquote><div>Things are just different for =
commas. It should be natural semicolons and commas are different, because t=
hey look different. If you want sequenced evaluation, use semicolons explic=
itly. This is clean, tidy and easy.<br><br>The true bad thing is, whether a=
 comma indicates sequenced evaluation or not is context-sensitive. It depen=
ds on whether it is an operator or not. This syntactic inconsistency is stu=
pid, since it confuse peoples a lot, and the only usage is to overcome the =
fact of lacking of sequenced evaluation constructs in clauses of some state=
ments. This is the limitation of standard C. Both expression statements and=
 lambda expressions can work around it nicely, but as a consequence of that=
 random design, (possibly insanely overloaded) &quot;operator,&quot; remain=
s painful in C++. Forcing left-to-right evaluation on function calls would =
eliminate the inconsistency between overloaded and builtin &quot;operator,&=
quot;, however, also make the whole design of language uglier. To be pragma=
tic, I don&#39;t care about it too much, but it indeed screw up the process=
 of reasoning a lot, which should be desperately needed by people here (to =
avoid turning the language into totally unsustainable mess).<br><br>(On the=
 other hand, &quot;statement&quot; itself is a kind of shortsighted artifac=
t, as a result of poor programing language theory practice in some &quot;mo=
dern&quot; cases. But this is another story.)<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div></div=
><div>The second rationale strikes me as completely back to front:</div><di=
v><br></div><div>=E2=80=9CIf you don=E2=80=99t know how they are done on va=
rious machines, you won=E2=80=99t be tempted to take advantage of a particu=
lar implementation.=E2=80=9D</div><div><br></div><div>The problem isn=E2=80=
=99t that people are tempted to take advantage. The problem is that they wr=
ite something, test it, find that it works, and move on. All the while bein=
g blissfully ignorant that the working code, as a matter of fact, has undef=
ined behavior.</div><div><br></div><div>But, hey, this is C++, right? If we=
 can make it more complicated, let=E2=80=99s!</div><div><br><blockquote typ=
e=3D"cite"><div><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>My fa=
ith in humanity is lost forever.</div></div></div></div></div></blockquote>=
<div><br></div>I=E2=80=99m not quite as bleak as that, but close. After twe=
nty-five years of writing C++ on a daily basis, I am still spending a large=
 part of my programming effort watching myself over my own shoulder, just t=
o avoid shooting myself in the foot with something silly, such as forgettin=
g to disable a copy constructor or accidentally relying on undefined evalua=
tion order. It=E2=80=99s tedious, to say the least.</div><div><br></div><di=
v>And, after twenty-five years, I=E2=80=99m still unable to say that C++ is=
 easy. It isn=E2=80=99t, period. If performance doesn=E2=80=99t matter, giv=
e me Java or C# any day. (And, no, I=E2=80=99m not a Java weenie. But Java =
*is* easy, certainly when compared to C++.)</div><br></div></blockquote><di=
v>Do you really know who are trying to make it more complicated? And how?<b=
r><br>C++ isn&#39;t easy. True. But it could have been easier.<br><br>And t=
he core language of Java is actually more complicated than C++. See the Jav=
a language specification.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6934b9a2-8bb3-4d5d-a4fe-30861ea993fd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6934b9a2-8bb3-4d5d-a4fe-30861ea993fd=
%40isocpp.org</a>.<br />

------=_Part_6953_924326143.1457438413669--
------=_Part_6952_682046077.1457438413668--

.

------=_Part_3368_1028162051.1457439195122
Content-Type: multipart/alternative;
 boundary="----=_Part_3369_271407891.1457439195123"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+=
8=E4=B8=8A=E5=8D=8810:34:59=EF=BC=8CPatrice Roy=E5=86=99=E9=81=93=EF=BC=9A
>
> No shooting for using the =C2=ABJ=C2=BB word, at least not from me.
>
> @Miro : =C2=ABThey expect things to be evaluated from left to right, beca=
use=20
> that is the order they typed it in. And it always works. Except when it=
=20
> doesn't (but only in C/C++)=C2=BB. If my memory is correct, Lisp / Scheme=
=20
> evaluated functions right-to-left. It was/is a specified order, though.
>
I don't inspect all Lisp dialects, but as previously mentioned, Scheme is=
=20
one notable contemporary example of unspecified evaluation order on=20
function application (procedural calls) operator and operands. This is in=
=20
the specification (e.g. RnRS) explicitly.

--=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/1153d5bf-fd1d-4468-b98a-fa1b64826679%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8810:34:59=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">No shooting for using the =C2=ABJ=C2=BB word, at least not fr=
om me.<br><br>@Miro : =C2=ABThey expect things to be evaluated from left to=
 right, because that is the order they typed it in. And it always works. Ex=
cept when it doesn&#39;t (but only in C/C++)=C2=BB. If my memory is correct=
, Lisp / Scheme evaluated functions right-to-left. It was/is a specified or=
der, though.</div></blockquote><div>I don&#39;t inspect all Lisp dialects, =
but as previously mentioned, Scheme=20
is one notable contemporary example of unspecified evaluation order on=20
function application (procedural calls) operator and operands. This is=20
in the specification (e.g. RnRS) explicitly.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1153d5bf-fd1d-4468-b98a-fa1b64826679%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1153d5bf-fd1d-4468-b98a-fa1b64826679=
%40isocpp.org</a>.<br />

------=_Part_3369_271407891.1457439195123--
------=_Part_3368_1028162051.1457439195122--

.

------=_Part_2518_1542325817.1457443909999
Content-Type: multipart/alternative;
 boundary="----=_Part_2519_1836400511.1457443909999"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+=
8=E4=B8=8A=E5=8D=8811:30:24=EF=BC=8CMichi Henning=E5=86=99=E9=81=93=EF=BC=
=9A

I disagree that this is about aesthetics. It=E2=80=99s not about aesthetics=
, it=E2=80=99s=20
> about people. Programmers (yes, they are people) are subject to all the=
=20
> same cognitive pitfalls and misconceptions as everyone else, no matter ho=
w=20
> much they should know better. They are people, after all. When I write =
=E2=80=9Ca"=20
> followed by "b=E2=80=9D, my brain, no matter how hard I might try to trai=
n myself=20
> otherwise, can play tricks on me and make me think =E2=80=9Ca followed by=
 b=E2=80=9D=20
> instead of =E2=80=9Cmaybe a first, or maybe b first=E2=80=9D.
>

This is about people, but not all people implemented that cognitive process=
=20
quite same. For example, I will see "a" and "b" simultaneously and then=20
analyzing them in parallel. Until the final synchronization of some piece=
=20
of translatable code (for C++, usually scanning until getting a full=20
statement or a declaration; for Lisp dialects, usually meeting the=20
enclosing ')' of a list) has been performed successfully, I will not assume=
=20
which of "a" and "b" comes first except for literal (lexical or syntactic)=
=20
order (often useless in later processes). Literal order is just one kind of=
=20
order, it has essentially nothing to do with evaluation in this process=20
model. If you have written an interpreter or a compiler, you may know this =
style=20
of separated processes is called "multi-pass" design. The illusion of=20
one-pass compilers is out of date because people now know they will not be=
=20
faster in general (though memory-efficient, however, for humans, huh?) but=
=20
almost always make things over-complicated *a lot*. (Note that I don't=20
train myself to write compilers before I find the rationale.)

Too many passes may be harmful, but at least 2 are needed, corresponding to=
=20
literal and semantic properties respectively, whose separation is quite=20
easy to be done unconsciously. Most practical languages have similar=20
separation in the specification, to make the syntactic and semantics stuff=
=20
stay distinct clearly, to ease the implementation of the language. It is=20
reasonable that this property should not only benefits implementation on=20
machines, but also for humans. So I tend to think your forced-in-one-pass n=
aive=20
way is somewhat premature optimization by intuition.

(BTW, C++ has specified many phases of translations, but some rules are so=
=20
awful, compilers cannot simply put semantic passes after parsing...)
=20

>
> The notation suggests an order, even though no order exists. That creates=
=20
> cognitive friction and invites mistakes.
>
> In C++, an expression with *n* terms has *n*! possible evaluation orders.=
=20
> In C# and Lisp, an expression with *n* terms has exactly one evaluation=
=20
> order. To me, any argument stating that undefined order is just as simple=
=20
> as a defined order is completely off the rails.
>
> There may be n!, n! + 1 or so on, but it is irrelevant unless you actuall=
y=20
count it. You should have just two options: to rely on the order, or not.=
=20
Which one is easier *after you have learned all the concerned rules of=20
language*? (Hint: which is longer?)=20

> @Hyman : see above. I am sad that code gets broken due to expectancies on=
=20
> the ordering of such statements, but I'm saddened that such code was=20
> written in the first place.
>
>
> It is unbelievably easy to write such code, and to write it even as a ver=
y=20
> diligent programmer. This is especially true, when I am forced to work wi=
th=20
> weird and wonderful legacy C++ APIs that were written by people who were,=
=20
> shall we say, less than competent. Such APIs quite often have=20
> innocent-looking function calls that take a value and return a value and,=
=20
> it just so happens, have internal side effects as well, often unbeknownst=
=20
> to the caller. Calling such functions in an unexpected order causes havoc=
..=20
> And, to be sure whether or not the functions are free of side-effects, I=
=20
> have to go and (recursively) read the source code of the API I have to ca=
ll=20
> into in its entirety, even though I couldn=E2=80=99t be less interested.=
=20
> (Documentation of side effects doesn=E2=80=99t help because most APIs don=
=E2=80=99t have=20
> documentation worth the electrons that are wasted for displaying the doc =
on=20
> a screen.)
>
> Also don=E2=80=99t tell me that people shouldn=E2=80=99t be writing such =
functions. I=20
> agree, they shouldn=E2=80=99t. But the reality of many popular C and C++ =
APIs out=20
> there is that they are full of such crimes. For an example, just look at=
=20
> the OpenGL APIs, which are basically one gigantic side effect.
>
> To me, insisting that f(g(), h()) should have undefined evaluation order=
=20
> is the same thing as stating
>
> =E2=80=9CThough shalt not ever call more than one function without an int=
ervening=20
> sequence point, unless you have read all of the code of all functions in=
=20
> their entirety, lest their side effects blow your leg off.=E2=80=9D
>
> This is not helpful to programmers.
>
> @Michi : I don't think the fact that there is no a priori ordering of suc=
h=20
> statements makes the language more complicated. Knowing they are unordere=
d=20
> (could be done in parallel should they be [[pure]] or whatever) or knowin=
g=20
> they are mandated to be evaluated in a specific order (right-to-left,=20
> left-to-right) seems of equivalent complexity to me.
>
>
> I strongly disagree with that. That=E2=80=99s because, intuitively and=20
> subconsciously, my brain whispers to me =E2=80=9Cfirst a, then b=E2=80=9D=
, when it sees=20
> f(a, b).
>
> Providing a left-to-right guarantee is more ordered than providing an=20
> unordered guarantee (bad pun intended).
>
> Even if the ordering was mandated, I'd avoid depending on it (if my=20
> company uses more than one programming language, porting an algorithm to=
=20
> other languages would be made unnecessarily complex due to this dependenc=
e;=20
> it's a very bad idea).
>
>
> This particular argument is a red herring, in my opinion. If I have to=20
> port an algorithm from one language to another, order of evaluation is=20
> typically a tenth-order issue, if that. There are far more important=20
> considerations than evaluation order when porting from C to Java, or vice=
=20
> versa.
>
It should be an important issue if you can't get it correct reliably, since=
=20
it is met so frequently. Actually you can't translate high-level languages=
=20
by direct (e.g. one-to-one) mapping in general, you have to keep some=20
intermediate representation in your brain. The separation of it and later=
=20
"code generation" process will give you chance to reconstruct the semantic=
=20
information in any (abstract) way you prefer (rather than in the form of=20
source or target language that confused you), including the order of=20
"expressions".

>
> The argument is a red herring for another reason: when I port from Java t=
o=20
> C++, if I blindly copy expressions, I implicitly rely on the defined=20
> evaluation order in Java that doesn=E2=80=99t exist in C++. In other word=
s, your=20
> objection is invalid because, whether C++ mandates left-to-right or=20
> unordered does not matter for porting from one language to another: C++=
=20
> will be wrong some of the time, regardless of which order it chooses.
>
> You will be punished if you blindly copy expressions in general. No one=
=20
guarantee the original intention (though "depending less" strategy=20
<https://en.wikipedia.org/wiki/Principle_of_least_privilege> is often safer=
=20
in many aspects) will not be misinterpreted. Garbage in, garbage out,=20
probably.=20

> @Michi : the dependency you are bringing forward is of another nature,=20
> being a data dependency where the first line influences the second one in=
=20
> an ordered sequence of instructions. I don't think anyone on this thread=
=20
> questions the idea of sequence per se, no matter what individual position=
s=20
> are.
>
>
> I didn=E2=80=99t think that anyone would mistake it for that. I came up w=
ith that=20
> example simply to illustrate the cognitive dissonance. In the statement=
=20
> case, what comes first is evaluated first. In the expression case, what=
=20
> comes first might be evaluated first, last, or somewhere in the middle.
>
> From a cognitive perspective, undefined evaluation order is much the same=
=20
> thing as pit with spikes at the bottom: it causes problems because it goe=
s=20
> against the grain of how people think. Ergonomically, undefined evaluatio=
n=20
> order a train wreck.
>
> This is also why I do not like the current proposal as it stands. It=20
> mandates left-to-right for only a subset of expressions, meaning the=20
> already-complex rules of C++ have yet again become even more complex=20
> because, after this change, I can=E2=80=99t just remember that =E2=80=9Ce=
valuation order is=20
> undefined.=E2=80=9D Instead, I now have to remember that =E2=80=9Cevaluat=
ion order is=20
> defined for the following cases, but not for any others=E2=80=9D.
>
> If the proposal makes it through in its current form, our style guide wil=
l=20
> gain a new rule. It=E2=80=99ll read something like this (I=E2=80=99m not =
making this up,=20
> trust me):
>
> =E2=80=9CDo not ever rely on evaluation order, even in cases where it is =
well=20
> defined. The rules of when evaluation order is defined are subtle, and an=
=20
> innocent change to an expression can destroy any previously well-defined=
=20
> order. Therefore, it is safest to not ever rely on evaluation order at al=
l.=E2=80=9D
>
> The first is true, since there is sufficient way to specify order reliabl=
y=20
regardless of such (subexpression) evaluation. However, not only the=20
evaluation order is subtle. You should also know there are rules about non-=
strict=20
semantics=20
<https://en.wikipedia.org/wiki/Evaluation_strategy#Non-strict_evaluation>,=
=20
for example, short circuit logical operators. This kind of rules imply the=
=20
order, and ignorance of them often make the written code even more subtle.=
=20
(Huh, are the operands around '&&' intended to be swappable? And you should=
=20
always know some other order of non-strict constructs like "then" always=20
comes after "if"'s condition clause, so does "?:"...) Note not only C++ has=
=20
suffered from these hard-coded builtin operator rules, but also those=20
insist on left-to-right evaluation. Only when the "generic" evaluation=20
order is occasionally the same to these special rules, they seems to be=20
"easy" enough.
=20

> And so we blissfully follow down the path of ever-increasing complexity,=
=20
> and wonder why it is so hard to hire good C++ programmers.
>
> Cheers,
>
> Michi.
>
>

--=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/90e4820b-0a45-4b79-b7e2-25438fed9aad%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8811:30:24=EF=BC=8CMichi Henning=
=E5=86=99=E9=81=93=EF=BC=9A<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 style=3D"word-wrap:break-word"><div>I disagree that this i=
s about aesthetics. It=E2=80=99s not about aesthetics, it=E2=80=99s about p=
eople. Programmers (yes, they are people) are subject to all the same cogni=
tive pitfalls and misconceptions as everyone else, no matter how much they =
should know better. They are people, after all. When I write =E2=80=9Ca&quo=
t; followed by &quot;b=E2=80=9D, my brain, no matter how hard I might try t=
o train myself otherwise, can play tricks on me and make me think =E2=80=9C=
a followed by b=E2=80=9D instead of =E2=80=9Cmaybe a first, or maybe b firs=
t=E2=80=9D.</div></div></blockquote><div><br>This is about people, but not =
all people implemented that cognitive process quite same. For example, I wi=
ll see &quot;a&quot; and &quot;b&quot; <span class=3D"op_dict3_font24 op_di=
ct3_marginRight">simultaneously and then analyzing them in parallel. Until =
the final synchronization of some piece of translatable code (for C++, usua=
lly scanning until getting a full statement or a declaration; for Lisp dial=
ects, usually meeting the enclosing &#39;)&#39; of a list) has been perform=
ed successfully, I will not assume which of &quot;a&quot; and &quot;b&quot;=
 comes first except for literal (lexical or syntactic) order (often useless=
 in later processes). Literal order is just one kind of order, it has essen=
tially nothing to do with evaluation in this process model. If you have wri=
tten an interpreter or a compiler, you may know this </span><span class=3D"=
op_dict3_font24 op_dict3_marginRight"><span class=3D"op_dict3_font24 op_dic=
t3_marginRight">style of </span>separated processes is called &quot;multi-p=
ass&quot; design. The illusion of one-pass compilers is out of date because=
 people now know they will not be faster in general (though memory-efficien=
t, however, for humans, huh?) but almost always make things over-complicate=
d <i>a lot</i>. (</span><span class=3D"op_dict3_font24 op_dict3_marginRight=
"><span class=3D"op_dict3_font24 op_dict3_marginRight">Note that I don&#39;=
t train myself to write compilers before I find the rationale.</span>)<br><=
br>Too many passes may be harmful, but at least 2 are needed, corresponding=
 to literal and semantic properties respectively, whose separation is quite=
 easy to be done unconsciously. Most practical languages have similar separ=
ation in the specification, to make the syntactic and semantics stuff stay =
distinct clearly, to ease the implementation of the language. It is reasona=
ble that this property should not only benefits implementation on machines,=
 but also for humans. So I tend to think your forced-in-one-pass </span><sp=
an class=3D"op_dict3_font24 op_dict3_marginRight"><span class=3D"op_dict3_f=
ont24 op_dict3_marginRight">naive </span>way is somewhat premature optimiza=
tion by intuition.<br><br>(BTW, C++ has specified many phases of translatio=
ns, but some rules are so awful, compilers cannot simply put semantic passe=
s after parsing...)</span><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 style=3D"word-wrap:break-word"><div><br></div><div>The=
 notation suggests an order, even though no order exists. That creates cogn=
itive friction and invites mistakes.</div><div><br></div><div>In C++, an ex=
pression with <i>n</i> terms has <i>n</i>! possible evaluation orders. In C=
# and Lisp, an expression with <i>n</i> terms has exactly one evaluation or=
der. To me, any argument stating that undefined order is just as simple as =
a defined order is completely off the rails.</div><div><br></div></div></bl=
ockquote><div>There may be n!, n! + 1 or so on, but it is irrelevant unless=
 you actually count it. You should have just two options: to rely on the or=
der, or not. Which one is easier <i>after you have learned all the concerne=
d rules of language</i>? (Hint: which is longer?) <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 style=3D"word-wrap:break-word"><div><blo=
ckquote type=3D"cite"><div><div dir=3D"ltr">@Hyman : see above. I am sad th=
at code gets broken due to expectancies on the ordering of such statements,=
 but I&#39;m saddened that such code was written in the first place.</div><=
/div></blockquote><div><br></div>It is unbelievably easy to write such code=
, and to write it even as a very diligent programmer. This is especially tr=
ue, when I am forced to work with weird and wonderful legacy C++ APIs that =
were written by people who were, shall we say, less than competent. Such AP=
Is quite often have innocent-looking function calls that take a value and r=
eturn a value and, it just so happens, have internal side effects as well, =
often unbeknownst to the caller. Calling such functions in an unexpected or=
der causes havoc. And, to be sure whether or not the functions are free of =
side-effects, I have to go and (recursively) read the source code of the AP=
I I have to call into in its entirety, even though I couldn=E2=80=99t be le=
ss interested. (Documentation of side effects doesn=E2=80=99t help because =
most APIs don=E2=80=99t have documentation worth the electrons that are was=
ted for displaying the doc on a screen.)</div><div><br></div><div>Also don=
=E2=80=99t tell me that people shouldn=E2=80=99t be writing such functions.=
 I agree, they shouldn=E2=80=99t. But the reality of many popular C and C++=
 APIs out there is that they are full of such crimes. For an example, just =
look at the OpenGL APIs, which are basically one gigantic side effect.</div=
><br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div s=
tyle=3D"word-wrap:break-word"><div></div><div>To me, insisting that f(g(), =
h()) should have undefined evaluation order is the same thing as stating</d=
iv><div><br></div><div><span style=3D"white-space:pre"> </span>=E2=80=9CTho=
ugh shalt not ever call more than one function without an intervening seque=
nce point, unless you have read all of the code of all functions in their e=
ntirety, lest their side effects blow your leg off.=E2=80=9D</div><div><br>=
</div><div>This is not helpful to programmers.</div><div><br><blockquote ty=
pe=3D"cite"><div><div dir=3D"ltr">@Michi : I don&#39;t think the fact that =
there is no a priori ordering of such statements makes the language more co=
mplicated. Knowing they are unordered (could be done in parallel should the=
y be [[pure]] or whatever) or knowing they are mandated to be evaluated in =
a specific order (right-to-left, left-to-right) seems of equivalent complex=
ity to me.</div></div></blockquote><div><br></div>I strongly disagree with =
that. That=E2=80=99s because, intuitively and subconsciously, my brain whis=
pers to me =E2=80=9Cfirst a, then b=E2=80=9D, when it sees f(a, b).</div><d=
iv><br></div><div>Providing a left-to-right guarantee is more ordered than =
providing an unordered guarantee (bad pun intended).</div><div><br><blockqu=
ote type=3D"cite"><div><div dir=3D"ltr"> Even if the ordering was mandated,=
 I&#39;d avoid depending on it (if my company uses more than one programmin=
g language, porting an algorithm to other languages would be made unnecessa=
rily complex due to this dependence; it&#39;s a very bad idea).<br></div></=
div></blockquote><div><br></div>This particular argument is a red herring, =
in my opinion. If I have to port an algorithm from one language to another,=
 order of evaluation is typically a tenth-order issue, if that. There are f=
ar more important considerations than evaluation order when porting from C =
to Java, or vice versa.</div></div></blockquote><div>It should be an import=
ant issue if you can&#39;t get it correct reliably, since it is met so freq=
uently. Actually you can&#39;t translate high-level languages by direct (e.=
g. one-to-one) mapping in general, you have to keep some intermediate repre=
sentation in your brain. The separation of it and later &quot;code generati=
on&quot; process will give you chance to reconstruct the semantic informati=
on in any (abstract) way you prefer (rather than in the form of source or t=
arget language that confused you), including the order of &quot;expressions=
&quot;.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><div><br></div><div>The argument is a red herring fo=
r another reason: when I port from Java to C++, if I blindly copy expressio=
ns, I implicitly rely on the defined evaluation order in Java that doesn=E2=
=80=99t exist in C++. In other words, your objection is invalid because, wh=
ether C++ mandates left-to-right or unordered does not matter for porting f=
rom one language to another: C++ will be wrong some of the time, regardless=
 of which order it chooses.</div><div><br></div></div></blockquote><div>You=
 will be punished if you blindly copy expressions in general. No one guaran=
tee the original intention (though <a href=3D"https://en.wikipedia.org/wiki=
/Principle_of_least_privilege">&quot;depending less&quot; strategy</a> is o=
ften safer in many aspects) will not be misinterpreted. Garbage in, garbage=
 out, probably. <br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 style=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><div><div di=
r=3D"ltr">@Michi : the dependency you are bringing forward is of another na=
ture, being a data dependency where the first line influences the second on=
e in an ordered sequence of instructions. I don&#39;t think anyone on this =
thread questions the idea of sequence per se, no matter what individual pos=
itions are.<br></div></div></blockquote><div><br></div>I didn=E2=80=99t thi=
nk that anyone would mistake it for that. I came up with that example simpl=
y to illustrate the cognitive dissonance. In the statement case, what comes=
 first is evaluated first. In the expression case, what comes first might b=
e evaluated first, last, or somewhere in the middle.</div><div><br></div><d=
iv>From a cognitive perspective, undefined evaluation order is much the sam=
e thing as pit with spikes at the bottom: it causes problems because it goe=
s against the grain of how people think. Ergonomically, undefined evaluatio=
n order a train wreck.</div><div><br></div><div>This is also why I do not l=
ike the current proposal as it stands. It mandates left-to-right for only a=
 subset of expressions, meaning the already-complex rules of C++ have yet a=
gain become even more complex because, after this change, I can=E2=80=99t j=
ust remember that =E2=80=9Cevaluation order is undefined.=E2=80=9D Instead,=
 I now have to remember that =E2=80=9Cevaluation order is defined for the f=
ollowing cases, but not for any others=E2=80=9D.</div><div><br></div><div>I=
f the proposal makes it through in its current form, our style guide will g=
ain a new rule. It=E2=80=99ll read something like this (I=E2=80=99m not mak=
ing this up, trust me):</div><div><br></div><div>=E2=80=9CDo not ever rely =
on evaluation order, even in cases where it is well defined. The rules of w=
hen evaluation order is defined are subtle, and an innocent change to an ex=
pression can destroy any previously well-defined order. Therefore, it is sa=
fest to not ever rely on evaluation order at all.=E2=80=9D</div><div><br></=
div></div></blockquote><div>The first is true, since there is sufficient wa=
y to specify order reliably regardless of such (subexpression) evaluation. =
However, not only the evaluation order is subtle. You should also know ther=
e are rules about <a href=3D"https://en.wikipedia.org/wiki/Evaluation_strat=
egy#Non-strict_evaluation">non-strict semantics</a>, for example, short cir=
cuit logical operators. This kind of rules imply the order, and ignorance o=
f them often make the written code even more subtle. (Huh, are the operands=
 around &#39;&amp;&amp;&#39; intended to be swappable? And you should alway=
s know some other order of non-strict constructs like &quot;then&quot; alwa=
ys comes after &quot;if&quot;&#39;s condition clause, so does &quot;?:&quot=
;...) Note not only C++ has suffered from these hard-coded builtin operator=
 rules, but also those insist on left-to-right evaluation. Only when the &q=
uot;generic&quot; evaluation order is occasionally the same to these specia=
l rules, they seems to be &quot;easy&quot; enough.<br></div><div>=C2=A0</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 style=3D"word-wrap:brea=
k-word"><div></div><div>And so we blissfully follow down the path of ever-i=
ncreasing complexity, and wonder why it is so hard to hire good C++ program=
mers.</div><div><br></div><div>Cheers,</div><div><br></div><div>Michi.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/90e4820b-0a45-4b79-b7e2-25438fed9aad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90e4820b-0a45-4b79-b7e2-25438fed9aad=
%40isocpp.org</a>.<br />

------=_Part_2519_1836400511.1457443909999--
------=_Part_2518_1542325817.1457443909999--

.

------=_Part_2732_85634337.1457445829304
Content-Type: multipart/alternative;
 boundary="----=_Part_2733_1187799948.1457445829305"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+=
8=E4=B8=8B=E5=8D=883:25:25=EF=BC=8CMichi Henning=E5=86=99=E9=81=93=EF=BC=9A
>
> Code written to a defined evaluation order is less expressive; one cannot=
=20
> know whether a particular order is intended or whether any order is OK.
>
> Well, with what we have now, if there is anything in an expression that=
=20
> has a side effect, I don=E2=80=99t know whether this is intended or not e=
ither.=20
> That=E2=80=99s assuming that I can even see the side effect. Otherwise, i=
f there=20
> are no side effects, I guess I know that any order is OK.
>
You can still not ensure the existence of particular side effect is=20
intended or not if the order is fixed. And now when there has more than one=
=20
unsequenced side effects on same scalar object, it causes UB and thus it=20
should not be intended. This assumption will not be true if the order is=20
fixed.=20

> It is less efficient, because certain code transformations (to reduce dat=
a=20
> dependencies, e.g.) and parallelisations are excluded.
>
> I would have thought that, in many cases, the compiler could still=20
> re-order under an as-if rule.
>

It is strictly harder because then one cannot directly permit compiler to=
=20
do such thing, and before such optimization the compiler has to *prove *it=
=20
will actually not violate the as-if rule, which is always (since the=20
required additional work was formally no-op) harder to implement and=20
hopefully always harmful to compiling performance.=20

> It is less maintainable, because one cannot reorder function arguments=20
> when changing APIs, reorder subexpressions, or merge changes without havi=
ng=20
> to consider all possible side effects.=20
>
> Yes, that=E2=80=99s the price of side effects, not evaluation order. Any =
side=20
> effects that might happen are just as damaging now as they would be with=
=20
> left-to-right evaluation. Because, right now, any order can happen. So, a=
ny=20
> reordering right now is potentially just as damaging as any re-ordering=
=20
> under a left-to-right rule. So, unless I=E2=80=99m missing something, I t=
hink this=20
> point is a red herring.
>

Fixed order evaluation actually encourages side effects to be put together=
=20
(in one full expression) more tightly, which may easily bring more work=20
because of more chances to guess whether it is intended.=20

> And I should also have mentioned programmers whose code assumes RTL=20
> evaluation order; I don't feel any particular identification with them, b=
ut=20
> would point out that your proposed change massively privileges your code=
=20
> debt over theirs.=20
>
>
> What code debt? Sorry, I=E2=80=99m just not following. How can left-to-ri=
ght=20
> disadvantage or privilege anyone, given that, currently, there no defined=
=20
> order whatsoever?
>
=20
Do you think the amount of work to modify gcc or clang (to be=20
then-conformant) would be equal?=20

> Michi.
>
>

--=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/282c0376-1dc1-4b84-9448-8e284009b2f2%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=883:25:25=EF=BC=8CMichi Henning=
=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 style=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><div><p dir=
=3D"ltr">Code written to a defined evaluation order is less expressive; one=
 cannot know whether a particular order is intended or whether any order is=
 OK.</p></div></blockquote><div>Well, with what we have now, if there is an=
ything in an expression that has a side effect, I don=E2=80=99t know whethe=
r this is intended or not either. That=E2=80=99s assuming that I can even s=
ee the side effect. Otherwise, if there are no side effects, I guess I know=
 that any order is OK.</div></div></div></blockquote><div>You can still not=
 ensure the existence of particular side effect is intended or not if the o=
rder is fixed. And now when there has more than one unsequenced side effect=
s on same scalar object, it causes UB and thus it should not be intended. T=
his assumption will not be true if the order is fixed. <br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div=
><blockquote type=3D"cite"><div><p dir=3D"ltr"> It is less efficient, becau=
se certain code transformations (to reduce data dependencies, e.g.) and par=
allelisations are excluded.</p></div></blockquote><div>I would have thought=
 that, in many cases, the compiler could still re-order under an as-if rule=
..</div></div></div></blockquote><div><br>It is strictly harder because then=
 one cannot directly permit compiler to do such thing, and before such opti=
mization the compiler has to <i>prove </i>it will actually not violate the =
as-if rule, which is always (since the required additional work was formall=
y no-op) harder to implement and hopefully always harmful to compiling perf=
ormance. <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 style=
=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><div><p dir=3D"ltr=
">It is less maintainable, because one cannot reorder function arguments wh=
en changing APIs, reorder subexpressions, or merge changes without having t=
o consider all possible side effects. </p></div></blockquote><div>Yes, that=
=E2=80=99s the price of side effects, not evaluation order. Any side effect=
s that might happen are just as damaging now as they would be with left-to-=
right evaluation. Because, right now, any order can happen. So, any reorder=
ing right now is potentially just as damaging as any re-ordering under a le=
ft-to-right rule. So, unless I=E2=80=99m missing something, I think this po=
int is a red herring.</div></div></div></blockquote><div><br>Fixed order ev=
aluation actually encourages side effects to be put together (in one=20
full expression) more tightly, which may easily bring more work because of =
more chances to=20
guess whether it is intended. <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><div><blockquote type=3D"cite"><div><p dir=3D"ltr">And I sho=
uld also have mentioned programmers whose code assumes RTL evaluation order=
; I don&#39;t feel any particular identification with them, but would point=
 out that your proposed change massively privileges your code debt over the=
irs. </p></div></blockquote><div><br></div>What code debt? Sorry, I=E2=80=
=99m just not following. How can left-to-right disadvantage or privilege an=
yone, given that, currently, there no defined order whatsoever?</div></div>=
</blockquote><div>=C2=A0<br>Do you think the amount of work to modify gcc o=
r clang (to be then-conformant) would be equal? <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 style=3D"word-wrap:break-word"><div></div>=
<div>Michi.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/282c0376-1dc1-4b84-9448-8e284009b2f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/282c0376-1dc1-4b84-9448-8e284009b2f2=
%40isocpp.org</a>.<br />

------=_Part_2733_1187799948.1457445829305--
------=_Part_2732_85634337.1457445829304--

.

------=_Part_78_1747315501.1457447538082
Content-Type: multipart/alternative;
 boundary="----=_Part_79_258431101.1457447538082"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+=
8=E4=B8=8A=E5=8D=883:56:12=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 04.03.2016 um 13:04 schrieb 'Edward Catmur' via ISO C++ Standard -=20
> Future Proposals:
>
>
> On 4 Mar 2016 12:29, "Miro Knejp" <miro....@gmail.com <javascript:>>=20
> wrote:
> >
> > People have wildly different expectations, and that largely depends on=
=20
> what they start programming with. And people who have never programmed=20
> before usually have expectations that have no connection to the technical=
=20
> reality. Those who grow up speaking and writing a left-to-right language=
=20
> have it ingrained in their head that all sequences of things are=20
> let-to-right as that is the direction they read and write in. In math cla=
ss=20
> they are given the exercise f(g(x) + h(x)) and how do they intuitively=20
> solve it? They calculate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, the=
n f(c).=20
> Try getting rid of this intuition after applying it for several years=20
> during the phase of your live where the brain solidifies such patterns.=
=20
> They expect the programming language to work the same because programming=
=20
> and math are very closely related, and all the modern languages actually=
=20
> *do* fulfill this expectation.
> >
>
> What do they do when given f(x) + g(x) * h(x)?
>
> Mathematical formulae - which programming language expressions model - do=
=20
> not have side effects, so intermediate results can be computed in any=20
> order.=20
>
> That's not the point. It doesn't matter whether math formulas have no sid=
e=20
> effects or that they can be evaluated in any order. What matters is the=
=20
> underlying psychology of the people who do the exercise, and later the=20
> programming course. If they're used to a certain way of solving these=20
> problems and have trained that during a critical phase of brain develomen=
t,=20
> they apply it to everything. It's a pattern, and our brain is very good a=
t=20
> identifying and applying patterns, but horrifically bad at abandoning=20
> existing patterns.
>

The syntactic design of many ALGOL-derived languages are clearly effected=
=20
by the math notation. Learners of such languages are often required have=20
background knowledge about such syntax style. So the underlying psychology=
=20
of most people should be similar at first. When there are semantics stuff,=
=20
things get complicated, because there is nothing "side effects" in=20
traditional math they have learned. Syntax of math can be considered bad=20
pattern, but the fresh rules of semantics should be not.

> Any reasonably competent student will exploit this to perform CSE and=20
> other rewriting tricks to simplify the computation, so the similar tricks=
=20
> the compiler performs should be intimately familiar.=20
>
> They do CSE because it saves *them* work, because it saves *them* time on=
=20
> exams, but a machine doesn't care about that and most class or home=20
> exercises finish computing quickly enough that execution time doesn't=20
> matter. I argue that most beginner programming students pay optimization=
=20
> absolutely no attention and probably don't even know such a thing exists.=
=20
> Those with prior experience, yes, but the majority don't until they=20
> actually get into courses that deal with data structures, algorithms,=20
> complexities and code transforming optimizations, but until they receive=
=20
> (and understand) that knowledge they may have already decided that C++ is=
 a=20
> stupid language and that Java is all the awesomeness.
>

Nothing wrong.

> Then, too, when they're learning fundamentals of programming languages,=
=20
> they will discover that the order in which term rewriting rules are appli=
ed=20
> can affect, if not the result, then certainly how long it takes to reach=
=20
> the result and even whether the result is reached at all (for weakly=20
> normalizing terms).
>
> This kind of transformation is only dealt with in courses that actually=
=20
> teach the topic of code transforming optimizations. But often theses=20
> courses are considered advanced, and sometimes even optional. The topic o=
f=20
> "performance" is typically only touched on in courses dealing with data=
=20
> structures and algorithmic complexity, but those exercises don't have=20
> execution times which are saved by subexpression reordering, they are=20
> tailored specifically to show the difference betwen a hash map and a link=
ed=20
> list.
>

Still nothing wrong.=20

> So I don't believe that programming novices expect any particular=20
> evaluation order, irrespective of what human languages they speak.=20
>
> Don't underestimate the impact a language can have on how people think.=
=20
> There is evidence pointing in the direction that native one speaks langua=
ge=20
> does influence the way of thinking and problem solving (see the weak=20
> Sapir-Whorf hypothesis) and that it even changes how a bilingual thinks=
=20
> when switching between languages.
>
> They can't find the difference between natural language and artificial=20
languages by themselves. They care too little of the purpose. So they=20
loose. Fair enough.

Furthermore, when we teach people programming we tell them "the machine=20
> executes this line, then this line, then this line, ...". Is it really to=
o=20
> far-fetched that they would recognize a pattern, transform it and apply t=
he=20
> concept to expressions as well? "the machine executes this expression, th=
en=20
> this expression after the comma, then this expression after the next comm=
a,=20
> ..."
>

You should never teach people a language by "line" if there is no such=20
primitive concept in that language. Line numbers are concerned with #line,=
=20
for editors, for debuggers... but should not be touched in most other time.=
=20
Nor you should teach them patterns. Patterns are usually result of language=
=20
learners' work. There indeed no many "patterns" to teach. Teach them *why*,=
=20
not only *how*. Further, machines are not always good abstraction to be=20
taught, even harmful=20
<http://pchiusano.blogspot.hk/2013/05/the-future-of-software-end-of-apps-an=
d.html>
..


--=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/121e6a05-9252-4311-8241-ec0986c0b94d%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=883:56:12=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 04.03.2016 um 13:04 schrieb &#39;Edward Catmur&#39; via ISO C++ Stan=
dard
    - Future Proposals:<br>
    <blockquote type=3D"cite">
      <p dir=3D"ltr"><br>
        On 4 Mar 2016 12:29, &quot;Miro Knejp&quot; &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"y6xf9FYhBQAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">miro....@gmail.com</a>&=
gt;
        wrote:<br>
        &gt;<br>
        &gt; People have wildly different expectations, and that largely
        depends on what they start programming with. And people who have
        never programmed before usually have expectations that have no
        connection to the technical reality. Those who grow up speaking
        and writing a left-to-right language have it ingrained in their
        head that all sequences of things are let-to-right as that is
        the direction they read and write in. In math class they are
        given the exercise f(g(x) + h(x)) and how do they intuitively
        solve it? They calculate a=3Dg(x) first, then b=3Dh(x), then c=3Da+=
b,
        then f(c). Try getting rid of this intuition after applying it
        for several years during the phase of your live where the brain
        solidifies such patterns. They expect the programming language
        to work the same because programming and math are very closely
        related, and all the modern languages actually *do* fulfill this
        expectation.<br>
        &gt;</p>
      <p dir=3D"ltr">What do they do when given f(x) + g(x) * h(x)?</p>
      <p dir=3D"ltr">Mathematical formulae - which programming language
        expressions model - do not have side effects, so intermediate
        results can be computed in any order. </p>
    </blockquote>
    That&#39;s not the point. It doesn&#39;t matter whether math formulas h=
ave
    no side effects or that they can be evaluated in any order. What
    matters is the underlying psychology of the people who do the
    exercise, and later the programming course. If they&#39;re used to a
    certain way of solving these problems and have trained that during a
    critical phase of brain develoment, they apply it to everything.
    It&#39;s a pattern, and our brain is very good at identifying and
    applying patterns, but horrifically bad at abandoning existing
    patterns.<br></div></blockquote><div><br>The syntactic design of many A=
LGOL-derived languages are clearly effected by the math notation. Learners =
of such languages are often required have background knowledge about such s=
yntax style. So the underlying psychology of most people should be similar =
at first. When there are semantics stuff, things get complicated, because t=
here is nothing &quot;side effects&quot; in traditional math they have lear=
ned. Syntax of math can be considered bad pattern, but the fresh rules of s=
emantics should be not.<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <blockquote type=3D"cite">
      <p dir=3D"ltr">Any reasonably competent student will exploit this to
        perform CSE and other rewriting tricks to simplify the
        computation, so the similar tricks the compiler performs should
        be intimately familiar. </p>
    </blockquote>
    They do CSE because it saves *them* work, because it saves *them*
    time on exams, but a machine doesn&#39;t care about that and most class
    or home exercises finish computing quickly enough that execution
    time doesn&#39;t matter. I argue that most beginner programming student=
s
    pay optimization absolutely no attention and probably don&#39;t even
    know such a thing exists. Those with prior experience, yes, but the
    majority don&#39;t until they actually get into courses that deal with
    data structures, algorithms, complexities and code transforming
    optimizations, but until they receive (and understand) that
    knowledge they may have already decided that C++ is a stupid
    language and that Java is all the awesomeness.<br></div></blockquote><d=
iv><br>Nothing wrong.<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <blockquote type=3D"cite">
      <p dir=3D"ltr">Then, too, when they&#39;re learning fundamentals of
        programming languages, they will discover that the order in
        which term rewriting rules are applied can affect, if not the
        result, then certainly how long it takes to reach the result and
        even whether the result is reached at all (for weakly
        normalizing terms).</p>
    </blockquote>
    This kind of transformation is only dealt with in courses that
    actually teach the topic of code transforming optimizations. But
    often theses courses are considered advanced, and sometimes even
    optional. The topic of &quot;performance&quot; is typically only touche=
d on in
    courses dealing with data structures and algorithmic complexity, but
    those exercises don&#39;t have execution times which are saved by
    subexpression reordering, they are tailored specifically to show the
    difference betwen a hash map and a linked list.<br></div></blockquote><=
div><br>Still nothing wrong. <br></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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    <blockquote type=3D"cite">
      <p dir=3D"ltr"> So I don&#39;t believe that programming novices expec=
t
        any particular evaluation order, irrespective of what human
        languages they speak. </p>
    </blockquote>
    Don&#39;t underestimate the impact a language can have on how people
    think. There is evidence pointing in the direction that native one
    speaks language does influence the way of thinking and problem
    solving (see the weak Sapir-Whorf hypothesis) and that it even
    changes how a bilingual thinks when switching between languages.<br>
    <br></div></blockquote><div>They can&#39;t find the difference between =
natural language and artificial languages by themselves. They care too litt=
le of the purpose. So they loose. Fair enough.<br><br> </div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    Furthermore, when we teach people programming we tell them &quot;the
    machine executes this line, then this line, then this line, ...&quot;. =
Is
    it really too far-fetched that they would recognize a pattern,
    transform it and apply the concept to expressions as well? &quot;the
    machine executes this expression, then this expression after the
    comma, then this expression after the next comma, ...&quot;<br></div></=
blockquote><div><br>You should never teach people a language by &quot;line&=
quot; if there is no such primitive concept in that language. Line numbers =
are concerned with #line, for editors, for debuggers... but should not be t=
ouched in most other time. Nor you should teach them patterns. Patterns are=
 usually result of language learners&#39; work. There indeed no many &quot;=
patterns&quot; to teach. Teach them <i>why</i>, not only <i>how</i>. Furthe=
r, machines are not always good abstraction to be taught, <a href=3D"http:/=
/pchiusano.blogspot.hk/2013/05/the-future-of-software-end-of-apps-and.html"=
>even harmful</a>.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/121e6a05-9252-4311-8241-ec0986c0b94d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/121e6a05-9252-4311-8241-ec0986c0b94d=
%40isocpp.org</a>.<br />

------=_Part_79_258431101.1457447538082--
------=_Part_78_1747315501.1457447538082--

.

This is a multi-part message in MIME format.
--------------010500060805030804030500
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 08.03.2016 um 13:00 schrieb FrankHB1989:
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8A=E5=8D=889:06:46=EF=BC=8CMichi Henning=E5=86=99=E9=81=93=EF=BC=
=9A
>
>>     They didn't forget. They seem to have deliberately left it
>>     unspecified.
>>
>>     Source: https://www.eskimo.com/~scs/cclass/notes/sx7c.html
>>     <https://www.eskimo.com/%7Escs/cclass/notes/sx7c.html>
>>
>>     quote: The moral is that writing code that depends on order of
>>     evaluation is a bad programming practice in any language.
>>     Naturally, it is necessary to know what things to avoid, but if
>>     you don't know /how/ they are done on various machines, you won't
>>     be tempted to take advantage of a particular implementation.
>
>     I just dug out my 1st edition copy of K&R and, yes, those words
>     are indeed there (final para on page 50).
>
>     To state that =E2=80=9Cwriting code that depends on order of evaluati=
on is
>     bad programming practice in any language=E2=80=9D is to make a rather
>     sweeping statement, and one that is contradicted by many modern
>     languages. In K&R=E2=80=99s defense, the statement was made almost 40
>     years ago.
>
>     We use sequencing all the time. If I write
>
>     a =3D b;
>     c +=3D 2 * a;
>
>     I=E2=80=99d be rather surprised if the compiler were to re-order thes=
e two
>     statements.
>
>
> Certainly not allowed. Semicolons has clear semantics to forbid this.
>
>     But, for some reason I can=E2=80=99t quite follow, doing the same thi=
ng
>     for expressions is considered bad, even though a complex
>     expression is just a sequence of simple statements. Why anyone
>     would deem it desirable for things to be evaluated in any order is
>     beyond me, hypothetical compile-time optimizations notwithstanding.
>
> Things are just different for commas. It should be natural semicolons=20
> and commas are different, because they look different. If you want=20
> sequenced evaluation, use semicolons explicitly. This is clean, tidy=20
> and easy.
>
> The true bad thing is, whether a comma indicates sequenced evaluation=20
> or not is context-sensitive. It depends on whether it is an operator=20
> or not. This syntactic inconsistency is stupid, since it confuse=20
> peoples a lot, and the only usage is to overcome the fact of lacking=20
> of sequenced evaluation constructs in clauses of some statements. This=20
> is the limitation of standard C. Both expression statements and lambda=20
> expressions can work around it nicely, but as a consequence of that=20
> random design, (possibly insanely overloaded) "operator," remains=20
> painful in C++. Forcing left-to-right evaluation on function calls=20
> would eliminate the inconsistency between overloaded and builtin=20
> "operator,", however, also make the whole design of language uglier.
Do you have a definition for "uglier"? As you say yourself, turning=20
"this list of values is unorderd but this one is" into "all lists of=20
values are ordered" makes the language more consistent. How is making=20
the language more consistent making it "uglier"? Neurological psychology=20
shows us again and again that people do better remembering and applying=20
rules the fewer exceptions they have. The less cognitive load it takes=20
to keep all these exceptions in mind the more is available to analyse=20
and solve the actual problem we're working on. Our active short-term=20
working memory is very limited and can fill up very quickly with junk=20
like this.

--=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/56DEECB4.3090604%40gmail.com.

--------------010500060805030804030500
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 08.03.2016 um 13:00 schrieb FrankHB1989:<br>
    <blockquote
      cite=3D"mid:6934b9a2-8bb3-4d5d-a4fe-30861ea993fd@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=
=94 UTC+8=E4=B8=8A=E5=8D=889:06:46=EF=BC=8CMichi Henning=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 style=3D"word-wrap:break-word">
            <div>
              <blockquote type=3D"cite">
                <div>
                  <div dir=3D"ltr">
                    <div>
                      <div class=3D"gmail_quote">
                        <div>They didn't forget. They seem to have
                          deliberately left it unspecified.</div>
                        <div><br>
                        </div>
                        <div>Source: <a moz-do-not-send=3D"true"
                            href=3D"https://www.eskimo.com/%7Escs/cclass/no=
tes/sx7c.html"
                            target=3D"_blank" rel=3D"nofollow"
                            onmousedown=3D"this.href=3D'https://www.google.=
com/url?q\75https%3A%2F%2Fwww.eskimo.com%2F~scs%2Fcclass%2Fnotes%2Fsx7c.htm=
l\46sa\75D\46sntz\0751\46usg\75AFQjCNFNt-xFm-Lk2Woh-HktQAS-ncTJ2Q';return
                            true;"
                            onclick=3D"this.href=3D'https://www.google.com/=
url?q\75https%3A%2F%2Fwww.eskimo.com%2F~scs%2Fcclass%2Fnotes%2Fsx7c.html\46=
sa\75D\46sntz\0751\46usg\75AFQjCNFNt-xFm-Lk2Woh-HktQAS-ncTJ2Q';return
                            true;">https://www.eskimo.com/~scs/<wbr>cclass/=
notes/sx7c.html</a></div>
                        <div><br>
                        </div>
                        <div>quote:=C2=A0<font color=3D"#ff0000"><span
                              style=3D"font-family:'Times New
                              Roman';font-size:inherit">The moral is
                              that writing code that depends on order of
                              evaluation is a bad programming practice
                              in any language. Naturally, it is
                              necessary to know what things to avoid,
                              but if you don't know=C2=A0</span><i
                              style=3D"font-family:'Times New
                              Roman';font-size:inherit">how</i><span
                              style=3D"font-family:'Times New
                              Roman';font-size:inherit">=C2=A0they are done
                              on various machines, you won't be tempted
                              to take advantage of a particular
                              implementation.</span>=C2=A0</font></div>
                      </div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <div><br>
              </div>
              I just dug out my 1st edition copy of K&amp;R and, yes,
              those words are indeed there (final para on page 50).</div>
            <div><br>
            </div>
            <div>To state that =E2=80=9Cwriting code that depends on order =
of
              evaluation is bad programming practice in any language=E2=80=
=9D is
              to make a rather sweeping statement, and one that is
              contradicted by many modern languages. In K&amp;R=E2=80=99s
              defense, the statement was made almost 40 years ago.</div>
            <div><br>
            </div>
            <div>We use sequencing all the time. If I write</div>
            <div><br>
            </div>
            <div>a =3D b;</div>
            <div>c +=3D 2 * a;</div>
            <div><br>
            </div>
            <div>I=E2=80=99d be rather surprised if the compiler were to
              re-order these two statements.</div>
          </div>
        </blockquote>
        <div><br>
          Certainly not allowed. Semicolons has clear semantics to
          forbid this.<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 style=3D"word-wrap:break-word">
            <div>But, for some reason I can=E2=80=99t quite follow, doing t=
he
              same thing for expressions is considered bad, even though
              a complex expression is just a sequence of simple
              statements. Why anyone would deem it desirable for things
              to be evaluated in any order is beyond me, hypothetical
              compile-time optimizations notwithstanding.</div>
            <div><br>
            </div>
          </div>
        </blockquote>
        <div>Things are just different for commas. It should be natural
          semicolons and commas are different, because they look
          different. If you want sequenced evaluation, use semicolons
          explicitly. This is clean, tidy and easy.<br>
          <br>
          The true bad thing is, whether a comma indicates sequenced
          evaluation or not is context-sensitive. It depends on whether
          it is an operator or not. This syntactic inconsistency is
          stupid, since it confuse peoples a lot, and the only usage is
          to overcome the fact of lacking of sequenced evaluation
          constructs in clauses of some statements. This is the
          limitation of standard C. Both expression statements and
          lambda expressions can work around it nicely, but as a
          consequence of that random design, (possibly insanely
          overloaded) "operator," remains painful in C++. Forcing
          left-to-right evaluation on function calls would eliminate the
          inconsistency between overloaded and builtin "operator,",
          however, also make the whole design of language uglier.</div>
      </div>
    </blockquote>
    Do you have a definition for "uglier"? As you say yourself, turning
    "this list of values is unorderd but this one is" into "all lists of
    values are ordered" makes the language more consistent. How is
    making the language more consistent making it "uglier"? Neurological
    psychology shows us again and again that people do better
    remembering and applying rules the fewer exceptions they have. The
    less cognitive load it takes to keep all these exceptions in mind
    the more is available to analyse and solve the actual problem we're
    working on. Our active short-term working memory is very limited and
    can fill up very quickly with junk like this.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/56DEECB4.3090604%40gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/ms=
gid/std-proposals/56DEECB4.3090604%40gmail.com</a>.<br />

--------------010500060805030804030500--

.

------=_Part_7170_1572317387.1457451429123
Content-Type: multipart/alternative;
 boundary="----=_Part_7171_1982989851.1457451429123"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+=
8=E4=B8=8A=E5=8D=8811:23:41=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 05.03.2016 um 03:52 schrieb 'Edward Catmur' via ISO C++ Standard -=20
> Future Proposals:
>
>
> On 5 Mar 2016 10:36, "Miro Knejp" <miro....@gmail.com <javascript:>>=20
> wrote:
> >
> > Am 05.03.2016 um 02:36 schrieb 'Edward Catmur' via ISO C++ Standard -=
=20
> Future Proposals:
> >>
> >>
> >> On 5 Mar 2016 09:07, "Dilip Ranganathan" < <javascript:>
> misc....@gmail.com <javascript:>> wrote:
> >> >
> >> > There is NO evidence that compilers are exploiting the unspecified=
=20
> order of evaluation to produce blazingly fast and optimized code (unless=
=20
> you think mere re-ordering of such expressions is an optimization in=20
> itself). I think to make this discussion concrete one must present (at=20
> least a hypothetical) example where such freedom can potentially be used =
by=20
> the compiler in a reasonable way and how mandating an order can break the=
=20
> observable behaviour of a program.
> >> > =20
> >>
> >> This was presented in a previous instance of this thread. I don't have=
=20
> access to it right now, but it was from Qt and it took the form f(g(a +=
=20
> this->x), this->x) where the compiler would not be able to prove that g d=
id=20
> not modify this->x. Under free ordering the compiler can hoist the access=
=20
> to this->x out of the expression.
> >
> > And without knowing what the author actually intended, regardless what=
=20
> the compiler does it has a 50% chance of doing the wrong thing. If the=20
> order is undefined it's basically russian roulette with every compilation=
..=20
> If the order is defined compilers *always* do either the right or wrong=
=20
> thing consistently, making it easier to spot and fix the bug. And yeah,=
=20
> code reviews and whatnot. Fact is, reviewers are humans prone to the same=
=20
> predispositions and faults as everyone else. If the reviewer happens to s=
ee=20
> the same intent as the author (which is likely written in a commit messag=
e,=20
> subconciously priming the reviewer) and it doesn't ring a bell then=20
> congratulations, a nondeterministic bug just slipped past code review.=20
> Hilarity ensues after a bunch of completely ridiculous sounding bug repor=
ts.
>
> With good code there is no Russian roulette; any ordering is acceptable,=
=20
> although some may be more efficient than others. Code written to bad APIs=
=20
> can still be made good enough by sequencing explicitly.=20
>
> Again this whole "good code" thing. Where is this fantasy land you're=20
> talking about and how do I get in? In the real world not every programmer=
=20
> is a perfect superhuman being that never makes mistakes. Prople writing=
=20
> code make mistakes. People reviewing code make mistakes. The degree of=20
> expertise only reduces the frequency, but it still happens. Or are you=20
> denying that fact and you never make mistakes?
>

This has nothing to do with modification of language rules. Any attempt to=
=20
make occasional wrong use of the language looks not so bad through the=20
language specification will not help. It will not dramatically make your=20
code better, if not worse by hiding the related bugs. The behavior of the=
=20
program might be accidentally as same as expectation based on previously=20
wrong assumptions, but certainly not "good" because the bias of the=20
intention, though you can find excuses to pretend it is good enough more=20
easily.

Note that as a developer, I want steady code which produce reliable=20
programs, not some black magic with bug-to-bug compatibility which=20
accidentally works for particular revision and environment. The base=20
priority of the bugs has nothing to do with if it is behavioral. In fact a=
=20
bug in code which does not alter the behavior of particular revision of the=
=20
program is often harder to deal with.

> > As much as I support the notion that only good code should be written,=
=20
> that's simply not the reality. Bad code will always be written either due=
=20
> to incompetence or ignorance. Sometimes you can do something about it and=
=20
> sometimes you just have to live with it. The harder it is for someone to =
do=20
> the wrong thing by default the better.
>
> You shouldn't have to pay for what you don't use. If you write good code,=
=20
> either by conscious effort or by selecting APIs that naturally promote go=
od=20
> code, then you shouldn't have to pay a penalty to protect people writing=
=20
> bad code from the consequences of their mistakes.=20
>
> There are many preconditions here. I am convinced everyone is making a=20
> conscious effort to write good code to the best of their abilities. It ju=
st=20
> so happens that not everybody agrees what "good" code is. Inexperienced=
=20
> programmers don't see problems where experienced programmers cringe.=20
> Someone writing only mobile applications their entire life will have a=20
> vastly different understanding of what "good" code is compared to someone=
=20
> working their entire life on video game engines. "good" code is such a=20
> subjective notion. Code that was considerd "good" C++ 20 years ago is=20
> frowned upon today.
>
> How exactly does one select an API that promotes good code? How much time=
=20
> do I spend researching APIs before knowing which of them promote good cod=
e?=20
> How many lines of code do I have to write against an API before realizing=
=20
> it's not promoting good code, and do I then rewrite my application agains=
t=20
> a new API and wait for the cycle to repeat? How do I know that in advance=
?=20
> For what definiton of "good"? What if there is only one API available? If=
=20
> the vendor of a device gives me their API and it doesn't promotes good=20
> code, I have no choice but to accept it because there is no alternative a=
nd=20
> no way of making them change it.
>
> What people *shouldn't* do or have to pay for is one thing. People also=
=20
> shouldn't drive drunk. What happens in reality is very different.=20
> Unfortunately ideologies are just that. I feel like you're enormously=20
> oversimplifying the problem....
>
=20
"Good" has no absolutely meaning here. It is hard to define "good" in a=20
global order, but it is doable to define "better" or "worse" in strict=20
partial order. If there is undesired property of code A but every other=20
property is equivalent (in "good enough" sense) with that of code B, than A=
=20
is strictly worse than B. Another difficulty is that binary relationship=20
does not compose. Usually you can't just mix arbitrary better pieces of=20
code to produce better result since there may be consequences based on=20
dependencies. However in case like changing evaluation order, there exists=
=20
few dependencies. So you can get better result by summing the better local=
=20
changes up. Thus the first step is to get better code locally until it is=
=20
good enough. When you can't find undesired property of the code locally,=20
that piece of code is good.=20

As of which sets of property of code are undesired, it depends. There seems=
=20
to be one problem: how to get consensus. I want the code do no more, no=20
less than I want it to do. Once there are enough resources to make it=20
feasible, every other consequence is undesired. This strategy makes it=20
easier to extend reasonable many "better" results from local to global, to=
=20
keep code good enough as possible in the long term.


--=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/33ca386c-304d-4f4a-9312-1d8bd46bcb86%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=8811:23:41=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 05.03.2016 um 03:52 schrieb &#39;Edward Catmur&#39; via ISO C++ Stan=
dard
    - Future Proposals:<br>
    <blockquote type=3D"cite">
      <p dir=3D"ltr"><br>
        On 5 Mar 2016 10:36, &quot;Miro Knejp&quot; &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"h45LRcI5BQAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">miro....@gmail.com</a>&=
gt;
        wrote:<br>
        &gt;<br>
        &gt; Am 05.03.2016 um 02:36 schrieb &#39;Edward Catmur&#39; via ISO=
 C++
        Standard - Future Proposals:<br>
        &gt;&gt;<br>
        &gt;&gt;<br>
        &gt;&gt; On 5 Mar 2016 09:07, &quot;Dilip Ranganathan&quot; &lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"h45LRcI5BQA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;"></a><a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"h45LRcI5BQAJ=
" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return =
true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">misc....@=
gmail.com</a>&gt;
        wrote:<br>
        &gt;&gt; &gt;<br>
        &gt;&gt; &gt; There is NO evidence that compilers are exploiting
        the unspecified order of evaluation to produce blazingly fast
        and optimized code (unless you think mere re-ordering of such
        expressions is an optimization in itself). I think to make this
        discussion concrete one must present (at least a hypothetical)
        example where such freedom can potentially be used by the
        compiler in a reasonable way and how mandating an order can
        break the observable behaviour of a program.<br>
        &gt;&gt; &gt; =C2=A0<br>
        &gt;&gt;<br>
        &gt;&gt; This was presented in a previous instance of this
        thread. I don&#39;t have access to it right now, but it was from Qt
        and it took the form f(g(a + this-&gt;x), this-&gt;x) where the
        compiler would not be able to prove that g did not modify
        this-&gt;x. Under free ordering the compiler can hoist the
        access to this-&gt;x out of the expression.<br>
        &gt;<br>
        &gt; And without knowing what the author actually intended,
        regardless what the compiler does it has a 50% chance of doing
        the wrong thing. If the order is undefined it&#39;s basically
        russian roulette with every compilation. If the order is defined
        compilers *always* do either the right or wrong thing
        consistently, making it easier to spot and fix the bug. And
        yeah, code reviews and whatnot. Fact is, reviewers are humans
        prone to the same predispositions and faults as everyone else.
        If the reviewer happens to see the same intent as the author
        (which is likely written in a commit message, subconciously
        priming the reviewer) and it doesn&#39;t ring a bell then
        congratulations, a nondeterministic bug just slipped past code
        review. Hilarity ensues after a bunch of completely ridiculous
        sounding bug reports.</p>
      <p dir=3D"ltr">With good code there is no Russian roulette; any
        ordering is acceptable, although some may be more efficient than
        others. Code written to bad APIs can still be made good enough
        by sequencing explicitly. </p>
    </blockquote>
    Again this whole &quot;good code&quot; thing. Where is this fantasy lan=
d
    you&#39;re talking about and how do I get in? In the real world not
    every programmer is a perfect superhuman being that never makes
    mistakes. Prople writing code make mistakes. People reviewing code
    make mistakes. The degree of expertise only reduces the frequency,
    but it still happens. Or are you denying that fact and you never
    make mistakes?<br></div></blockquote><div><br>This has nothing to do wi=
th modification of language rules. Any attempt to make occasional wrong use=
 of the language looks not so bad through the language specification will n=
ot help. It will not dramatically make your code better, if not worse by hi=
ding the related bugs. The behavior of the program might be accidentally as=
 same as expectation based on previously wrong assumptions, but certainly n=
ot &quot;good&quot; because the bias of the intention, though you can find =
excuses to pretend it is good enough more easily.<br><br>Note that as a dev=
eloper, I want steady code which produce reliable programs, not some black =
magic with bug-to-bug compatibility which accidentally works for particular=
 revision and environment. The base priority of the bugs has nothing to do =
with if it is behavioral. In fact a bug in code which does not alter the be=
havior of particular revision of the program is often harder to deal with.<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>
    <blockquote type=3D"cite">
      <p dir=3D"ltr">&gt; As much as I support the notion that only good
        code should be written, that&#39;s simply not the reality. Bad code
        will always be written either due to incompetence or ignorance.
        Sometimes you can do something about it and sometimes you just
        have to live with it. The harder it is for someone to do the
        wrong thing by default the better.</p>
      <p dir=3D"ltr">You shouldn&#39;t have to pay for what you don&#39;t u=
se. If
        you write good code, either by conscious effort or by selecting
        APIs that naturally promote good code, then you shouldn&#39;t have
        to pay a penalty to protect people writing bad code from the
        consequences of their mistakes. </p>
    </blockquote>
    There are many preconditions here. I am convinced everyone is making
    a conscious effort to write good code to the best of their
    abilities. It just so happens that not everybody agrees what &quot;good=
&quot;
    code is. Inexperienced programmers don&#39;t see problems where
    experienced programmers cringe. Someone writing only mobile
    applications their entire life will have a vastly different
    understanding of what &quot;good&quot; code is compared to someone work=
ing
    their entire life on video game engines. &quot;good&quot; code is such =
a
    subjective notion. Code that was considerd &quot;good&quot; C++ 20 year=
s ago
    is frowned upon today.<br><br></div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    How exactly does one select an API that promotes good code? How much
    time do I spend researching APIs before knowing which of them
    promote good code? How many lines of code do I have to write against
    an API before realizing it&#39;s not promoting good code, and do I then
    rewrite my application against a new API and wait for the cycle to
    repeat? How do I know that in advance? For what definiton of &quot;good=
&quot;?
    What if there is only one API available? If the vendor of a device
    gives me their API and it doesn&#39;t promotes good code, I have no
    choice but to accept it because there is no alternative and no way
    of making them change it.<br>
    <br>
    What people *shouldn&#39;t* do or have to pay for is one thing. People
    also shouldn&#39;t drive drunk. What happens in reality is very
    different. Unfortunately ideologies are just that. I feel like
    you&#39;re enormously oversimplifying the problem....</div></blockquote=
><div>=C2=A0<br>&quot;Good&quot; has no absolutely meaning here. It is hard=
 to define &quot;good&quot; in a global order, but it is doable to=20
define &quot;better&quot; or &quot;worse&quot; in strict partial order. If =
there is=20
undesired property of code A but every other property is equivalent (in=20
&quot;good enough&quot; sense) with that of code B, than A is strictly wors=
e than=20
B. Another difficulty is that binary relationship does not compose.=20
Usually you can&#39;t just mix arbitrary better pieces of code to produce=
=20
better result since there may be consequences based on dependencies.=20
However in case like changing evaluation order, there exists few=20
dependencies. So you can get better result by summing the better local=20
changes up. Thus the first step is to get better code locally until it=20
is good enough. When you can&#39;t find undesired property of the code=20
locally, that piece of code is good. <br><br>As of which sets of property o=
f code are undesired, it depends. There seems to be one problem: how to get=
 consensus. I want the code do no more, no less than I want it to do. Once =
there are enough resources to make it feasible, every other consequence is =
undesired. This strategy makes it easier to extend reasonable many &quot;be=
tter&quot; results from local to global, to keep code good enough as possib=
le in the long term.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/33ca386c-304d-4f4a-9312-1d8bd46bcb86%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/33ca386c-304d-4f4a-9312-1d8bd46bcb86=
%40isocpp.org</a>.<br />

------=_Part_7171_1982989851.1457451429123--
------=_Part_7170_1572317387.1457451429123--

.

This is a multi-part message in MIME format.
--------------090100030101080607080504
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 08.03.2016 um 15:32 schrieb FrankHB1989:
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UT=
C+8=E4=B8=8A=E5=8D=883:56:12=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
>     Am 04.03.2016 um 13:04 schrieb 'Edward Catmur' via ISO C++
>     Standard - Future Proposals:
>>
>>
>>     On 4 Mar 2016 12:29, "Miro Knejp" <miro....@gmail.com
>>     <javascript:>> wrote:
>>     >
>>     > People have wildly different expectations, and that largely
>>     depends on what they start programming with. And people who have
>>     never programmed before usually have expectations that have no
>>     connection to the technical reality. Those who grow up speaking
>>     and writing a left-to-right language have it ingrained in their
>>     head that all sequences of things are let-to-right as that is the
>>     direction they read and write in. In math class they are given
>>     the exercise f(g(x) + h(x)) and how do they intuitively solve it?
>>     They calculate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, then f(c=
).
>>     Try getting rid of this intuition after applying it for several
>>     years during the phase of your live where the brain solidifies
>>     such patterns. They expect the programming language to work the
>>     same because programming and math are very closely related, and
>>     all the modern languages actually *do* fulfill this expectation.
>>     >
>>
>>     What do they do when given f(x) + g(x) * h(x)?
>>
>>     Mathematical formulae - which programming language expressions
>>     model - do not have side effects, so intermediate results can be
>>     computed in any order.
>>
>     That's not the point. It doesn't matter whether math formulas have
>     no side effects or that they can be evaluated in any order. What
>     matters is the underlying psychology of the people who do the
>     exercise, and later the programming course. If they're used to a
>     certain way of solving these problems and have trained that during
>     a critical phase of brain develoment, they apply it to everything.
>     It's a pattern, and our brain is very good at identifying and
>     applying patterns, but horrifically bad at abandoning existing
>     patterns.
>
>
> The syntactic design of many ALGOL-derived languages are clearly=20
> effected by the math notation. Learners of such languages are often=20
> required have background knowledge about such syntax style. So the=20
> underlying psychology of most people should be similar at first. When=20
> there are semantics stuff, things get complicated, because there is=20
> nothing "side effects" in traditional math they have learned. Syntax=20
> of math can be considered bad pattern, but the fresh rules of=20
> semantics should be not.
Back then only few people did study computer science, and those were=20
usually like-minded people (i.e. nerds) who came into university with=20
tons of similar prior knowledge. Today we have millions of students=20
leaving school at 18 and entering computer science studies since it=20
became mainstream. Today these students have vastly different=20
backgrounds in education and interests and it's dangerous to assume=20
otherwise. Many of them had no prior exposure to programming at all, but=20
that doesn't automatically mean they cannot become great programmers. We=20
shouldn't "require" any further background knowledge from students than=20
what they get from the school or university curriculums. The easier we=20
can make it for people to understand the language and the underlying=20
concepts, apply it on their own, and keep them motivated and intersted=20
the better for the industry. There aren't going to be less programming=20
jobs in the future, so much is pretty much certain. And I'd prefer these=20
graduates to not be scared of C++ but to proudly say it is one of their=20
favorites. These people also need to have a proper understanding of the=20
software+hardware interaction (something I see missing a lot today),=20
which they won't get if they are only exposed to C# or Java because they=20
abandoned C++ due to its inconsistencies and frustration points.
>
>>     Any reasonably competent student will exploit this to perform CSE
>>     and other rewriting tricks to simplify the computation, so the
>>     similar tricks the compiler performs should be intimately familiar.
>>
>     They do CSE because it saves *them* work, because it saves *them*
>     time on exams, but a machine doesn't care about that and most
>     class or home exercises finish computing quickly enough that
>     execution time doesn't matter. I argue that most beginner
>     programming students pay optimization absolutely no attention and
>     probably don't even know such a thing exists. Those with prior
>     experience, yes, but the majority don't until they actually get
>     into courses that deal with data structures, algorithms,
>     complexities and code transforming optimizations, but until they
>     receive (and understand) that knowledge they may have already
>     decided that C++ is a stupid language and that Java is all the
>     awesomeness.
>
>
> Nothing wrong.
What do you mean by that? That there's nothing wrong with young students=20
being frustrated by C++ and not explore it further and instead join the=20
crowd of ignorant developers who get a panic attack when hearing the=20
word "pointer"? I want as many computer science students as possible to=20
like and use C++ because that includes the understanding of the=20
underlying machine interfaction engineering principles they may never=20
learn in any of those fancy higher-level languages.

If young people don't want to learn and use C++ there is either a=20
problem with the language, or the theacher, or both. The more=20
compilcated the rules get and the more exceptions there are the more=20
difficult we make it for newcomers.
>
>>     Then, too, when they're learning fundamentals of programming
>>     languages, they will discover that the order in which term
>>     rewriting rules are applied can affect, if not the result, then
>>     certainly how long it takes to reach the result and even whether
>>     the result is reached at all (for weakly normalizing terms).
>>
>     This kind of transformation is only dealt with in courses that
>     actually teach the topic of code transforming optimizations. But
>     often theses courses are considered advanced, and sometimes even
>     optional. The topic of "performance" is typically only touched on
>     in courses dealing with data structures and algorithmic
>     complexity, but those exercises don't have execution times which
>     are saved by subexpression reordering, they are tailored
>     specifically to show the difference betwen a hash map and a linked
>     list.
>
>
> Still nothing wrong.
>
>>     So I don't believe that programming novices expect any particular
>>     evaluation order, irrespective of what human languages they speak.
>>
>     Don't underestimate the impact a language can have on how people
>     think. There is evidence pointing in the direction that native one
>     speaks language does influence the way of thinking and problem
>     solving (see the weak Sapir-Whorf hypothesis) and that it even
>     changes how a bilingual thinks when switching between languages.
>
> They can't find the difference between natural language and artificial=20
> languages by themselves. They care too little of the purpose. So they=20
> loose. Fair enough.
It's very easy to say something like this when you already are an=20
expert. But I'm talking about 18 year olds who enter university and have=20
to learn all of this for the first time in their lives. They are the=20
future of C++ programmers and if we fail to get them to do and like C++=20
then the language as a basis for community and infrastructure has a=20
massive problem.

--=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/56DEF329.5010104%40gmail.com.

--------------090100030101080607080504
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 08.03.2016 um 15:32 schrieb FrankHB1989:<br>
    <blockquote
      cite=3D"mid:121e6a05-9252-4311-8241-ec0986c0b94d@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=
=AD UTC+8=E4=B8=8A=E5=8D=883:56:12=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;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000"> Am 04.03.2016 um 13:04
            schrieb 'Edward Catmur' via ISO C++ Standard - Future
            Proposals:<br>
            <blockquote type=3D"cite">
              <p dir=3D"ltr"><br>
                On 4 Mar 2016 12:29, "Miro Knejp" &lt;<a
                  moz-do-not-send=3D"true" href=3D"javascript:"
                  target=3D"_blank" gdf-obfuscated-mailto=3D"y6xf9FYhBQAJ"
                  rel=3D"nofollow"
                  onmousedown=3D"this.href=3D'javascript:';return true;"
                  onclick=3D"this.href=3D'javascript:';return true;"><a cla=
ss=3D"moz-txt-link-abbreviated" href=3D"mailto:miro....@gmail.com">miro....=
@gmail.com</a></a>&gt;

                wrote:<br>
                &gt;<br>
                &gt; People have wildly different expectations, and that
                largely depends on what they start programming with. And
                people who have never programmed before usually have
                expectations that have no connection to the technical
                reality. Those who grow up speaking and writing a
                left-to-right language have it ingrained in their head
                that all sequences of things are let-to-right as that is
                the direction they read and write in. In math class they
                are given the exercise f(g(x) + h(x)) and how do they
                intuitively solve it? They calculate a=3Dg(x) first, then
                b=3Dh(x), then c=3Da+b, then f(c). Try getting rid of this
                intuition after applying it for several years during the
                phase of your live where the brain solidifies such
                patterns. They expect the programming language to work
                the same because programming and math are very closely
                related, and all the modern languages actually *do*
                fulfill this expectation.<br>
                &gt;</p>
              <p dir=3D"ltr">What do they do when given f(x) + g(x) *
                h(x)?</p>
              <p dir=3D"ltr">Mathematical formulae - which programming
                language expressions model - do not have side effects,
                so intermediate results can be computed in any order. </p>
            </blockquote>
            That's not the point. It doesn't matter whether math
            formulas have no side effects or that they can be evaluated
            in any order. What matters is the underlying psychology of
            the people who do the exercise, and later the programming
            course. If they're used to a certain way of solving these
            problems and have trained that during a critical phase of
            brain develoment, they apply it to everything. It's a
            pattern, and our brain is very good at identifying and
            applying patterns, but horrifically bad at abandoning
            existing patterns.<br>
          </div>
        </blockquote>
        <div><br>
          The syntactic design of many ALGOL-derived languages are
          clearly effected by the math notation. Learners of such
          languages are often required have background knowledge about
          such syntax style. So the underlying psychology of most people
          should be similar at first. When there are semantics stuff,
          things get complicated, because there is nothing "side
          effects" in traditional math they have learned. Syntax of math
          can be considered bad pattern, but the fresh rules of
          semantics should be not.<br>
        </div>
      </div>
    </blockquote>
    Back then only few people did study computer science, and those were
    usually like-minded people (i.e. nerds) who came into university
    with tons of similar prior knowledge. Today we have millions of
    students leaving school at 18 and entering computer science studies
    since it became mainstream. Today these students have vastly
    different backgrounds in education and interests and it's dangerous
    to assume otherwise. Many of them had no prior exposure to
    programming at all, but that doesn't automatically mean they cannot
    become great programmers. We shouldn't "require" any further
    background knowledge from students than what they get from the
    school or university curriculums. The easier we can make it for
    people to understand the language and the underlying concepts, apply
    it on their own, and keep them motivated and intersted the better
    for the industry. There aren't going to be less programming jobs in
    the future, so much is pretty much certain. And I'd prefer these
    graduates to not be scared of C++ but to proudly say it is one of
    their favorites. These people also need to have a proper
    understanding of the software+hardware interaction (something I see
    missing a lot today), which they won't get if they are only exposed
    to C# or Java because they abandoned C++ due to its inconsistencies
    and frustration points.<br>
    <blockquote
      cite=3D"mid:121e6a05-9252-4311-8241-ec0986c0b94d@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <blockquote type=3D"cite">
              <p dir=3D"ltr">Any reasonably competent student will exploit
                this to perform CSE and other rewriting tricks to
                simplify the computation, so the similar tricks the
                compiler performs should be intimately familiar. </p>
            </blockquote>
            They do CSE because it saves *them* work, because it saves
            *them* time on exams, but a machine doesn't care about that
            and most class or home exercises finish computing quickly
            enough that execution time doesn't matter. I argue that most
            beginner programming students pay optimization absolutely no
            attention and probably don't even know such a thing exists.
            Those with prior experience, yes, but the majority don't
            until they actually get into courses that deal with data
            structures, algorithms, complexities and code transforming
            optimizations, but until they receive (and understand) that
            knowledge they may have already decided that C++ is a stupid
            language and that Java is all the awesomeness.<br>
          </div>
        </blockquote>
        <div><br>
          Nothing wrong.<br>
        </div>
      </div>
    </blockquote>
    What do you mean by that? That there's nothing wrong with young
    students being frustrated by C++ and not explore it further and
    instead join the crowd of ignorant developers who get a panic attack
    when hearing the word "pointer"? I want as many computer science
    students as possible to like and use C++ because that includes the
    understanding of the underlying machine interfaction engineering
    principles they may never learn in any of those fancy higher-level
    languages.<br>
    <br>
    If young people don't want to learn and use C++ there is either a
    problem with the language, or the theacher, or both. The more
    compilcated the rules get and the more exceptions there are the more
    difficult we make it for newcomers.<br>
    <blockquote
      cite=3D"mid:121e6a05-9252-4311-8241-ec0986c0b94d@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <blockquote type=3D"cite">
              <p dir=3D"ltr">Then, too, when they're learning fundamentals
                of programming languages, they will discover that the
                order in which term rewriting rules are applied can
                affect, if not the result, then certainly how long it
                takes to reach the result and even whether the result is
                reached at all (for weakly normalizing terms).</p>
            </blockquote>
            This kind of transformation is only dealt with in courses
            that actually teach the topic of code transforming
            optimizations. But often theses courses are considered
            advanced, and sometimes even optional. The topic of
            "performance" is typically only touched on in courses
            dealing with data structures and algorithmic complexity, but
            those exercises don't have execution times which are saved
            by subexpression reordering, they are tailored specifically
            to show the difference betwen a hash map and a linked list.<br>
          </div>
        </blockquote>
        <div><br>
          Still nothing wrong. <br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <blockquote type=3D"cite">
              <p dir=3D"ltr"> So I don't believe that programming novices
                expect any particular evaluation order, irrespective of
                what human languages they speak. </p>
            </blockquote>
            Don't underestimate the impact a language can have on how
            people think. There is evidence pointing in the direction
            that native one speaks language does influence the way of
            thinking and problem solving (see the weak Sapir-Whorf
            hypothesis) and that it even changes how a bilingual thinks
            when switching between languages.<br>
            <br>
          </div>
        </blockquote>
        <div>They can't find the difference between natural language and
          artificial languages by themselves. They care too little of
          the purpose. So they loose. Fair enough.<br>
        </div>
      </div>
    </blockquote>
    It's very easy to say something like this when you already are an
    expert. But I'm talking about 18 year olds who enter university and
    have to learn all of this for the first time in their lives. They
    are the future of C++ programmers and if we fail to get them to do
    and like C++ then the language as a basis for community and
    infrastructure has a massive problem.<br>
  </body>
</html>

<p></p>

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

--------------090100030101080607080504--

.

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

A computer program is the means whereby a computer is instructed to carry
out a computation.  Allowing the meaning of parts of a program to be
unspecified is a failure to provide specific instructions to the computer,
and to the extent that the author of the program did not mean this lack of
specificity, is a trap for the author and for all future users of the
program.

And this for the dubious prospect that the program may sometimes run a
little faster, and for the dubious pleasure of mocking the author for
failing to notice the problem.  There is nothing bad or ugly about relying
on order of evaluation.  The badness and ugliness is in taking an error in
programming language design and elevating that error into a principle.

On Tue, Mar 8, 2016 at 10:43 AM, Miro Knejp <miro.knejp@gmail.com> wrote:

> Am 08.03.2016 um 15:32 schrieb FrankHB1989:
>
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UT=
C+8=E4=B8=8A=E5=8D=883:56:12=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>>
>> Am 04.03.2016 um 13:04 schrieb 'Edward Catmur' via ISO C++ Standard -
>> Future Proposals:
>>
>>
>> On 4 Mar 2016 12:29, "Miro Knejp" <miro....@gmail.com> wrote:
>> >
>> > People have wildly different expectations, and that largely depends on
>> what they start programming with. And people who have never programmed
>> before usually have expectations that have no connection to the technica=
l
>> reality. Those who grow up speaking and writing a left-to-right language
>> have it ingrained in their head that all sequences of things are
>> let-to-right as that is the direction they read and write in. In math cl=
ass
>> they are given the exercise f(g(x) + h(x)) and how do they intuitively
>> solve it? They calculate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, th=
en f(c).
>> Try getting rid of this intuition after applying it for several years
>> during the phase of your live where the brain solidifies such patterns.
>> They expect the programming language to work the same because programmin=
g
>> and math are very closely related, and all the modern languages actually
>> *do* fulfill this expectation.
>> >
>>
>> What do they do when given f(x) + g(x) * h(x)?
>>
>> Mathematical formulae - which programming language expressions model - d=
o
>> not have side effects, so intermediate results can be computed in any
>> order.
>>
>> That's not the point. It doesn't matter whether math formulas have no
>> side effects or that they can be evaluated in any order. What matters is
>> the underlying psychology of the people who do the exercise, and later t=
he
>> programming course. If they're used to a certain way of solving these
>> problems and have trained that during a critical phase of brain develome=
nt,
>> they apply it to everything. It's a pattern, and our brain is very good =
at
>> identifying and applying patterns, but horrifically bad at abandoning
>> existing patterns.
>>
>
> The syntactic design of many ALGOL-derived languages are clearly effected
> by the math notation. Learners of such languages are often required have
> background knowledge about such syntax style. So the underlying psycholog=
y
> of most people should be similar at first. When there are semantics stuff=
,
> things get complicated, because there is nothing "side effects" in
> traditional math they have learned. Syntax of math can be considered bad
> pattern, but the fresh rules of semantics should be not.
>
> Back then only few people did study computer science, and those were
> usually like-minded people (i.e. nerds) who came into university with ton=
s
> of similar prior knowledge. Today we have millions of students leaving
> school at 18 and entering computer science studies since it became
> mainstream. Today these students have vastly different backgrounds in
> education and interests and it's dangerous to assume otherwise. Many of
> them had no prior exposure to programming at all, but that doesn't
> automatically mean they cannot become great programmers. We shouldn't
> "require" any further background knowledge from students than what they g=
et
> from the school or university curriculums. The easier we can make it for
> people to understand the language and the underlying concepts, apply it o=
n
> their own, and keep them motivated and intersted the better for the
> industry. There aren't going to be less programming jobs in the future, s=
o
> much is pretty much certain. And I'd prefer these graduates to not be
> scared of C++ but to proudly say it is one of their favorites. These peop=
le
> also need to have a proper understanding of the software+hardware
> interaction (something I see missing a lot today), which they won't get i=
f
> they are only exposed to C# or Java because they abandoned C++ due to its
> inconsistencies and frustration points.
>
> Any reasonably competent student will exploit this to perform CSE and
>> other rewriting tricks to simplify the computation, so the similar trick=
s
>> the compiler performs should be intimately familiar.
>>
>> They do CSE because it saves *them* work, because it saves *them* time o=
n
>> exams, but a machine doesn't care about that and most class or home
>> exercises finish computing quickly enough that execution time doesn't
>> matter. I argue that most beginner programming students pay optimization
>> absolutely no attention and probably don't even know such a thing exists=
..
>> Those with prior experience, yes, but the majority don't until they
>> actually get into courses that deal with data structures, algorithms,
>> complexities and code transforming optimizations, but until they receive
>> (and understand) that knowledge they may have already decided that C++ i=
s a
>> stupid language and that Java is all the awesomeness.
>>
>
> Nothing wrong.
>
> What do you mean by that? That there's nothing wrong with young students
> being frustrated by C++ and not explore it further and instead join the
> crowd of ignorant developers who get a panic attack when hearing the word
> "pointer"? I want as many computer science students as possible to like a=
nd
> use C++ because that includes the understanding of the underlying machine
> interfaction engineering principles they may never learn in any of those
> fancy higher-level languages.
>
> If young people don't want to learn and use C++ there is either a problem
> with the language, or the theacher, or both. The more compilcated the rul=
es
> get and the more exceptions there are the more difficult we make it for
> newcomers.
>
> Then, too, when they're learning fundamentals of programming languages,
>> they will discover that the order in which term rewriting rules are appl=
ied
>> can affect, if not the result, then certainly how long it takes to reach
>> the result and even whether the result is reached at all (for weakly
>> normalizing terms).
>>
>> This kind of transformation is only dealt with in courses that actually
>> teach the topic of code transforming optimizations. But often theses
>> courses are considered advanced, and sometimes even optional. The topic =
of
>> "performance" is typically only touched on in courses dealing with data
>> structures and algorithmic complexity, but those exercises don't have
>> execution times which are saved by subexpression reordering, they are
>> tailored specifically to show the difference betwen a hash map and a lin=
ked
>> list.
>>
>
> Still nothing wrong.
>
>> So I don't believe that programming novices expect any particular
>> evaluation order, irrespective of what human languages they speak.
>>
>> Don't underestimate the impact a language can have on how people think.
>> There is evidence pointing in the direction that native one speaks langu=
age
>> does influence the way of thinking and problem solving (see the weak
>> Sapir-Whorf hypothesis) and that it even changes how a bilingual thinks
>> when switching between languages.
>>
>> They can't find the difference between natural language and artificial
> languages by themselves. They care too little of the purpose. So they
> loose. Fair enough.
>
> It's very easy to say something like this when you already are an expert.
> But I'm talking about 18 year olds who enter university and have to learn
> all of this for the first time in their lives. They are the future of C++
> programmers and if we fail to get them to do and like C++ then the langua=
ge
> as a basis for community and infrastructure has a massive problem.
>
> --
> You received this message because you are 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/56DEF329.501=
0104%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56DEF329.50=
10104%40gmail.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/CAHSYqdYMfJQnJtxjy-bgqEy%3Dh3AtrEYqZYXFgiB5pixAr=
fDicg%40mail.gmail.com.

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

<div dir=3D"ltr">A computer program is the means whereby a computer is inst=
ructed to carry out a computation.=C2=A0 Allowing the meaning of parts of a=
 program to be unspecified is a failure to provide specific instructions to=
 the computer, and to the extent that the author of the program did not mea=
n this lack of specificity, is a trap for the author and for all future use=
rs of the program.<div><br></div><div>And this for the dubious prospect tha=
t the program may sometimes run a little faster, and for the dubious pleasu=
re of mocking the author for failing to notice the problem.=C2=A0 There is =
nothing bad or ugly about relying on order of evaluation.=C2=A0 The badness=
 and ugliness is in taking an error in programming language design and elev=
ating that error into a principle.</div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Tue, Mar 8, 2016 at 10:43 AM, Miro Knejp <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:miro.knejp@gmail.com" target=3D"_blan=
k">miro.knejp@gmail.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">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    Am 08.03.2016 um 15:32 schrieb FrankHB1989:<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=
=AD UTC+8=E4=B8=8A=E5=8D=883:56:12=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.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000"> Am 04.03.2016 um 13:04
            schrieb &#39;Edward Catmur&#39; via ISO C++ Standard - Future
            Proposals:<br>
            <blockquote type=3D"cite">
              <p dir=3D"ltr"><br>
                On 4 Mar 2016 12:29, &quot;Miro Knejp&quot; &lt;<a rel=3D"n=
ofollow"></a><a href=3D"mailto:miro....@gmail.com" target=3D"_blank">miro..=
...@gmail.com</a>&gt;

                wrote:<br>
                &gt;<br>
                &gt; People have wildly different expectations, and that
                largely depends on what they start programming with. And
                people who have never programmed before usually have
                expectations that have no connection to the technical
                reality. Those who grow up speaking and writing a
                left-to-right language have it ingrained in their head
                that all sequences of things are let-to-right as that is
                the direction they read and write in. In math class they
                are given the exercise f(g(x) + h(x)) and how do they
                intuitively solve it? They calculate a=3Dg(x) first, then
                b=3Dh(x), then c=3Da+b, then f(c). Try getting rid of this
                intuition after applying it for several years during the
                phase of your live where the brain solidifies such
                patterns. They expect the programming language to work
                the same because programming and math are very closely
                related, and all the modern languages actually *do*
                fulfill this expectation.<br>
                &gt;</p>
              <p dir=3D"ltr">What do they do when given f(x) + g(x) *
                h(x)?</p>
              <p dir=3D"ltr">Mathematical formulae - which programming
                language expressions model - do not have side effects,
                so intermediate results can be computed in any order. </p>
            </blockquote>
            That&#39;s not the point. It doesn&#39;t matter whether math
            formulas have no side effects or that they can be evaluated
            in any order. What matters is the underlying psychology of
            the people who do the exercise, and later the programming
            course. If they&#39;re used to a certain way of solving these
            problems and have trained that during a critical phase of
            brain develoment, they apply it to everything. It&#39;s a
            pattern, and our brain is very good at identifying and
            applying patterns, but horrifically bad at abandoning
            existing patterns.<br>
          </div>
        </blockquote>
        <div><br>
          The syntactic design of many ALGOL-derived languages are
          clearly effected by the math notation. Learners of such
          languages are often required have background knowledge about
          such syntax style. So the underlying psychology of most people
          should be similar at first. When there are semantics stuff,
          things get complicated, because there is nothing &quot;side
          effects&quot; in traditional math they have learned. Syntax of ma=
th
          can be considered bad pattern, but the fresh rules of
          semantics should be not.<br>
        </div>
      </div>
    </blockquote></span>
    Back then only few people did study computer science, and those were
    usually like-minded people (i.e. nerds) who came into university
    with tons of similar prior knowledge. Today we have millions of
    students leaving school at 18 and entering computer science studies
    since it became mainstream. Today these students have vastly
    different backgrounds in education and interests and it&#39;s dangerous
    to assume otherwise. Many of them had no prior exposure to
    programming at all, but that doesn&#39;t automatically mean they cannot
    become great programmers. We shouldn&#39;t &quot;require&quot; any furt=
her
    background knowledge from students than what they get from the
    school or university curriculums. The easier we can make it for
    people to understand the language and the underlying concepts, apply
    it on their own, and keep them motivated and intersted the better
    for the industry. There aren&#39;t going to be less programming jobs in
    the future, so much is pretty much certain. And I&#39;d prefer these
    graduates to not be scared of C++ but to proudly say it is one of
    their favorites. These people also need to have a proper
    understanding of the software+hardware interaction (something I see
    missing a lot today), which they won&#39;t get if they are only exposed
    to C# or Java because they abandoned C++ due to its inconsistencies
    and frustration points.<span class=3D""><br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <blockquote type=3D"cite">
              <p dir=3D"ltr">Any reasonably competent student will exploit
                this to perform CSE and other rewriting tricks to
                simplify the computation, so the similar tricks the
                compiler performs should be intimately familiar. </p>
            </blockquote>
            They do CSE because it saves *them* work, because it saves
            *them* time on exams, but a machine doesn&#39;t care about that
            and most class or home exercises finish computing quickly
            enough that execution time doesn&#39;t matter. I argue that mos=
t
            beginner programming students pay optimization absolutely no
            attention and probably don&#39;t even know such a thing exists.
            Those with prior experience, yes, but the majority don&#39;t
            until they actually get into courses that deal with data
            structures, algorithms, complexities and code transforming
            optimizations, but until they receive (and understand) that
            knowledge they may have already decided that C++ is a stupid
            language and that Java is all the awesomeness.<br>
          </div>
        </blockquote>
        <div><br>
          Nothing wrong.<br>
        </div>
      </div>
    </blockquote></span>
    What do you mean by that? That there&#39;s nothing wrong with young
    students being frustrated by C++ and not explore it further and
    instead join the crowd of ignorant developers who get a panic attack
    when hearing the word &quot;pointer&quot;? I want as many computer scie=
nce
    students as possible to like and use C++ because that includes the
    understanding of the underlying machine interfaction engineering
    principles they may never learn in any of those fancy higher-level
    languages.<br>
    <br>
    If young people don&#39;t want to learn and use C++ there is either a
    problem with the language, or the theacher, or both. The more
    compilcated the rules get and the more exceptions there are the more
    difficult we make it for newcomers.<span class=3D""><br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <blockquote type=3D"cite">
              <p dir=3D"ltr">Then, too, when they&#39;re learning fundament=
als
                of programming languages, they will discover that the
                order in which term rewriting rules are applied can
                affect, if not the result, then certainly how long it
                takes to reach the result and even whether the result is
                reached at all (for weakly normalizing terms).</p>
            </blockquote>
            This kind of transformation is only dealt with in courses
            that actually teach the topic of code transforming
            optimizations. But often theses courses are considered
            advanced, and sometimes even optional. The topic of
            &quot;performance&quot; is typically only touched on in courses
            dealing with data structures and algorithmic complexity, but
            those exercises don&#39;t have execution times which are saved
            by subexpression reordering, they are tailored specifically
            to show the difference betwen a hash map and a linked list.<br>
          </div>
        </blockquote>
        <div><br>
          Still nothing wrong. <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 bgcolor=3D"#FFFFFF" text=3D"#000000">
            <blockquote type=3D"cite">
              <p dir=3D"ltr"> So I don&#39;t believe that programming novic=
es
                expect any particular evaluation order, irrespective of
                what human languages they speak. </p>
            </blockquote>
            Don&#39;t underestimate the impact a language can have on how
            people think. There is evidence pointing in the direction
            that native one speaks language does influence the way of
            thinking and problem solving (see the weak Sapir-Whorf
            hypothesis) and that it even changes how a bilingual thinks
            when switching between languages.<br>
            <br>
          </div>
        </blockquote>
        <div>They can&#39;t find the difference between natural language an=
d
          artificial languages by themselves. They care too little of
          the purpose. So they loose. Fair enough.<br>
        </div>
      </div>
    </blockquote></span>
    It&#39;s very easy to say something like this when you already are an
    expert. But I&#39;m talking about 18 year olds who enter university and
    have to learn all of this for the first time in their lives. They
    are the future of C++ programmers and if we fail to get them to do
    and like C++ then the language as a basis for community and
    infrastructure has a massive problem.<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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/56DEF329.5010104%40gmail.com?utm_medi=
um=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/56DEF329.5010104%40gmail.com</a>.<b=
r>
</blockquote></div><br></div>

<p></p>

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

--001a1143f154c0af54052d8c2261--

.

------=_Part_217_1979941167.1457455713668
Content-Type: multipart/alternative;
 boundary="----=_Part_218_806084939.1457455713669"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8A=E5=8D=8812:43:36=EF=BC=8CPatrice Roy=E5=86=99=E9=81=93=EF=BC=9A
>
> I know people take this issue to heart, but I think it would be preferabl=
e=20
> for the debate if we collectively kept wording =C2=ABcalmed down=C2=BB.
>
> There are C++ idioms based on evaluation order, such as =C2=ABif (p && p-=
>f())=20
> for some pointer p that checks whether it's null before using it. I doubt=
=20
> anyone would claim that such idioms are =C2=ABa bad thing=C2=BB as they a=
re=20
> integrated in practice and have been for decades. It becomes annoying whe=
n=20
> someone overloads operator&& but apart from this, it works well and sets =
a=20
> nice precedent of code relying on evaluation order. There are others, of=
=20
> course, particularly with respect to operators.
>
> Yes, such idiom is bad in general (not specifically in C++). However, it=
=20
is not bad because of the evaluation order, but the whole special rule of=
=20
&&. The consequence of inconsistency between overloaded and builtin=20
operator&& makes trouble in generic code, for example, LWG issue 2114=20
<http://wg21.cmeerw.net/lwg/issue2114>. The null pointer itself is also=20
evil in such case, which makes 'p' evaluated more than once (what if 'p'=20
becomes 'x->y()->z()'?). To fix it completely you have to redesign the=20
major part of the type system, that costs too much. But since it does not=
=20
harm expressiveness, it is acceptable (in C++) and actually preferable if=
=20
&& is not overloaded here.

(Alternatives? Hmm... still ugly like C#'s scoped "using" if the right=20
operand is used more than once and locality is wanted:)
if(const auto p =3D ...)
   if(const auto q =3D p->f())
     //if(const auto r =3D q->g())

I think the point that some have made that they feel f(g(), h()) should=20
> have a well-defined order for g() and h() is clear. I don't have to agree=
=20
> with it but it's a clear point, and we'll most probably hear it in the=20
> discussions we'll have in Oulu as the proposal for evaluation order shoul=
d=20
> be brought up there. Maybe it will convince people better than it convinc=
ed=20
> me, we'll see. I have never seen the undefined ordering of g() and h() in=
=20
> such a case as expert-level knowledge (most of my students, if not all,=
=20
> learn that from the start), but I believe those who say their experience=
=20
> differs.
>
> I understand the potential efficiency loss argument with respect to the=
=20
> current undefined ordering. I'd need to see numbers, though, to be=20
> convinced. If we get [[pure]], this argument will be strengthened a bit (=
we=20
> could not evaluate sume functions that have been memoized, for example),=
=20
> but that's an =C2=ABif=C2=BB.
>
> The fact that depending on this newly-defined order risks becoming=20
> idiomatic is what worries me, and many others. As stated previously, this=
=20
> would make such things as f(i++,i++) acceptable practice with respect to=
=20
> the standard (even if not according to many coding standards) given that=
=20
> operator++(int) can be overloaded.
>
> As most vocal proponents of the =C2=ABstrong ordering=C2=BB position have=
 stated the=20
> fact that code reviews and available programming expertise as one of the=
=20
> main reasons (along with dependence on opaque libraries where side-effect=
s=20
> are not documented) why telling their colleagues not to write code which=
=20
> depends on undefined evaluation order is not sufficient in their opinion,=
=20
> I'm guessing the point holds for f(i++,i++) or for f(g(i++), h(i++)) or..=
..=20
> and that the same companies that ask for defined ordering in the=20
> contentious cases here would face similar quality control problems with=
=20
> defined ordering as without. If we open that can of worms, we have to=20
> accept the consequences, which deserves some collective though.
>
> The difference with imposed ordering would be consistency in code=20
> functioning or code crashing; an unwanted (to me at least) consequence=20
> would be that such things as f(g(i++), h(i++)) would become legitimate=20
> (probably not idiomatic at first, but no reason for it not to be at this=
=20
> point). It's part of the reflection we'll have to make. I see that sort o=
f=20
> code in C# programs when students choose that language, and they claim=20
> (rightfully) that it's allowed and well-defined. I recommend not to do su=
ch=20
> obscure things, but cannot fault their reasoning on a technical basis.
>
> The world won't crash if we define these beasts, and it's clearly not=20
> crashing today. It has nice and not-so-nice consequences on the code that=
=20
> people will write. Since I don't share the impression of the =C2=ABstrong=
=20
> ordering=C2=BB proponents that it's expert-level stuff to avoid f(g(), h(=
))=20
> cases, I must admit the not-so-nice consequences of defining the order of=
=20
> evaluation there seem more important to me than the upsides of defining=
=20
> this order, but my voice will only be one of many.
>
> Cheers!
>
>
>
>
>
> 2016-03-06 10:50 GMT-05:00 Miro Knejp <miro....@gmail.com <javascript:>>:
>
> Am 06.03.2016 um 15:11 schrieb 'Edward Catmur' via ISO C++ Standard -=20
> Future Proposals:
>
>
> On 6 Mar 2016 03:30, "Miro Knejp" <miro....@gmail.com <javascript:>>=20
> wrote:
> >
> > In a perfect world nobody would design bad code and all your=20
> dependencies would have perfect APIs. I would love to live in such a plac=
e.
>
> This place exists, your sarcasm notwithstanding.=20
>
> It's great that such places exist. Unfortunately not all of the millions=
=20
> of companies out there writing C++ code are like that. And some of those=
=20
> companies may produce code that gets used in lots of places. I can tell y=
ou=20
> that in the aviation industry there are many companies who have a quasi=
=20
> monopoly when it comes to the devices installed at airports worldwide and=
=20
> these companies provide APIs which you are forced to use because there is=
=20
> no alternative. These companies aren't filled with the kind of world-clas=
s=20
> experts we know from the standardization forums or speakers at C++ events=
,=20
> they have largely "average" C++ developers who happily continue writing=
=20
> Java++ because that's the best they know and either nobody cares to chang=
e=20
> that or management won't allow. Those who want change but can't get it=20
> leave and are replaced by some other drone who has to follow shitty=20
> existing coding guidelines. That is the reality of C++ in the world, not=
=20
> those tiny little perfect companies you mention and we'd all like to have=
..
>
> > Why do people think Bjarne & Co keep pushing for language features that=
=20
> make people write "good code by default"? Because right now it is way too=
=20
> easy to write bad code by default.
>
> So you propose to... make it even easier to write bad code by default? At=
=20
> least currently code depending on evaluation order can be detected when i=
t=20
> breaks.=20
>
> WTF? The code is only bad because it depends on something that is=20
> undefined. If the order *is* defined it's no longer bad (certainly not=20
> world-breaking bad). It's really fascinating how the association to bad=
=20
> code is upheld even if the conditions that make the code bad in the first=
=20
> place no longer existed. It used to be bad code to return objects by valu=
e=20
> but now that we have moves the cause for the bad code is gone and it is n=
ow=20
> considered good code, and it's still difficult for people to grasp and=20
> adapt who have avoided such code like the plague for 20+ years. Best=20
> practices change along changes to the language and library.
>
> It "can" be detecten when it breaks, sure. Maybe. If the planets are=20
> aligned so your compiler has a bad day. Or maybe the bug doesn't surface=
=20
> for years and then, suddenly, disaster. That's the whole point of this=20
> discussion. Bugs which cannot be deterministically reproduced on every=20
> developer's machine are the worst kind of bugs. Even worse is not knowing=
=20
> there is a bug at all until it's too late.
>
> So far the side opposing a fixed order of evaluation has failed to provid=
e=20
> any examples that clearly demonstrate where unspecified order of evaluati=
on=20
> is deliberately intended by the author, and important to the correctness =
or=20
> the efficiency of the code, bar some toy examples. All the arguments put=
=20
> forth so far go along the line of "don't be a scrub you fool and don't ma=
ke=20
> mistakes". That is a very elitist stance to have. Is that what the C++=20
> community is these days? A bunch of decade-long experts who don't want to=
=20
> make changes to the language because, really, you just have to "get good"=
,=20
> regardless how difficult that is for apprentices. Can't have newcomers ha=
ve=20
> it easier than we did, right? Is that what we're going to teach students=
=20
> now? "Just don't make mistakes and you'll be fine, oh and make sure to=20
> study this 1300 pages standardese document so you know all the rules and=
=20
> edge cases, and don't you dare forget a single rule lest you be considere=
d=20
> a bad programmer".
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56DC51D=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56DC51D0.20=
10501%40gmail.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/7e6b6b4c-3e2f-4240-b460-221d5d46fb41%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=8812:43:36=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><div><div>I know people take this issue to heart, but I =
think it would be preferable for the debate if we collectively kept wording=
 =C2=ABcalmed down=C2=BB.<br><br></div>There are C++ idioms based on evalua=
tion order, such as =C2=ABif (p &amp;&amp; p-&gt;f()) for some pointer p th=
at checks whether it&#39;s null before using it. I doubt anyone would claim=
 that such idioms are =C2=ABa bad thing=C2=BB as they are integrated in pra=
ctice and have been for decades. It becomes annoying when someone overloads=
 operator&amp;&amp; but apart from this, it works well and sets a nice prec=
edent of code relying on evaluation order. There are others, of course, par=
ticularly with respect to operators.<br><br></div></div></div></blockquote>=
<div>Yes, such idiom is bad in general (not specifically in C++). However, =
it is not bad because of the evaluation order, but the whole special rule o=
f &amp;&amp;. The consequence of inconsistency between overloaded and built=
in operator&amp;&amp; makes trouble in generic code, for example, <a href=
=3D"http://wg21.cmeerw.net/lwg/issue2114">LWG issue 2114</a>. The null poin=
ter itself is also evil in such case, which makes &#39;p&#39; evaluated mor=
e than once (what if &#39;p&#39; becomes &#39;x-&gt;y()-&gt;z()&#39;?). To =
fix it completely you have to redesign the major part of the type system, t=
hat costs too much. But since it does not harm expressiveness, it is accept=
able (in C++) and actually preferable if &amp;&amp; is not overloaded here.=
<br><br>(Alternatives? Hmm... still ugly like C#&#39;s scoped &quot;using&q=
uot; if the right operand is used more than once and locality is wanted:)<b=
r>if(const auto p =3D ...)<br>=C2=A0=C2=A0 if(const auto q =3D p-&gt;f())<b=
r>=C2=A0=C2=A0=C2=A0=C2=A0 //if(const auto r =3D q-&gt;g())<br><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></div=
>I think the point that some have made that they feel f(g(), h()) should ha=
ve a well-defined order for g() and h() is clear. I don&#39;t have to agree=
 with it but it&#39;s a clear point, and we&#39;ll most probably hear it in=
 the discussions we&#39;ll have in Oulu as the proposal for evaluation orde=
r should be brought up there. Maybe it will convince people better than it =
convinced me, we&#39;ll see. I have never seen the undefined ordering of g(=
) and h() in such a case as expert-level knowledge (most of my students, if=
 not all, learn that from the start), but I believe those who say their exp=
erience differs.<br><br></div><div>I understand the potential efficiency lo=
ss argument with respect to the current undefined ordering. I&#39;d need to=
 see numbers, though, to be convinced. If we get [[pure]], this argument wi=
ll be strengthened a bit (we could not evaluate sume functions that have be=
en memoized, for example), but that&#39;s an =C2=ABif=C2=BB.<br></div><div>=
<br>The fact that depending on this newly-defined order risks becoming idio=
matic is what worries me, and many others. As stated previously, this would=
 make such things as f(i++,i++) acceptable practice with respect to the sta=
ndard (even if not according to many coding standards) given that operator+=
+(int) can be overloaded.<br><br>As most vocal proponents of the =C2=ABstro=
ng ordering=C2=BB position have stated the fact that code reviews and avail=
able programming expertise as one of the main reasons (along with dependenc=
e on opaque libraries where side-effects are not documented) why telling th=
eir colleagues not to write code which depends on undefined evaluation orde=
r is not sufficient in their opinion, I&#39;m guessing the point holds for =
f(i++,i++) or for f(g(i++), h(i++)) or... and that the same companies that =
ask for defined ordering in the contentious cases here would face similar q=
uality control problems with defined ordering as without. If we open that c=
an of worms, we have to accept the consequences, which deserves some collec=
tive though.<br><br>The difference with imposed ordering would be consisten=
cy in code functioning or code crashing; an unwanted (to me at least) conse=
quence would be that such things as f(g(i++), h(i++)) would become legitima=
te (probably not idiomatic at first, but no reason for it not to be at this=
 point). It&#39;s part of the reflection we&#39;ll have to make. I see that=
 sort of code in C# programs when students choose that language, and they c=
laim (rightfully) that it&#39;s allowed and well-defined. I recommend not t=
o do such obscure things, but cannot fault their reasoning on a technical b=
asis.<br><br></div><div>The world won&#39;t crash if we define these beasts=
, and it&#39;s clearly not crashing today. It has nice and not-so-nice cons=
equences on the code that people will write. Since I don&#39;t share the im=
pression of the =C2=ABstrong ordering=C2=BB proponents that it&#39;s expert=
-level stuff to avoid f(g(), h()) cases, I must admit the not-so-nice conse=
quences of defining the order of evaluation there seem more important to me=
 than the upsides of defining this order, but my voice will only be one of =
many.<br><br></div><div>Cheers!<br></div><div><br></div><br><div><div><div>=
<div><div><br><br></div></div></div></div></div></div><div><br><div>2016-03=
-06 10:50 GMT-05:00 Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"eyIfhf2zBQAJ" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">miro....@gmail.com</a>&gt;<=
/span>:<br><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF"><span>
    Am 06.03.2016 um 15:11 schrieb &#39;Edward Catmur&#39; via ISO C++ Stan=
dard
    - Future Proposals:<br>
    <blockquote>
      <p dir=3D"ltr"><br>
        On 6 Mar 2016 03:30, &quot;Miro Knejp&quot; &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"eyIfhf2zBQAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">miro....@gmail.com</a>&=
gt;
        wrote:<br>
        &gt;<br>
        &gt; In a perfect world nobody would design bad code and all
        your dependencies would have perfect APIs. I would love to live
        in such a place.</p>
      <p dir=3D"ltr">This place exists, your sarcasm notwithstanding. </p>
    </blockquote></span>
    It&#39;s great that such places exist. Unfortunately not all of the
    millions of companies out there writing C++ code are like that. And
    some of those companies may produce code that gets used in lots of
    places. I can tell you that in the aviation industry there are many
    companies who have a quasi monopoly when it comes to the devices
    installed at airports worldwide and these companies provide APIs
    which you are forced to use because there is no alternative. These
    companies aren&#39;t filled with the kind of world-class experts we kno=
w
    from the standardization forums or speakers at C++ events, they have
    largely &quot;average&quot; C++ developers who happily continue writing=
 Java++
    because that&#39;s the best they know and either nobody cares to change
    that or management won&#39;t allow. Those who want change but can&#39;t=
 get
    it leave and are replaced by some other drone who has to follow
    shitty existing coding guidelines. That is the reality of C++ in the
    world, not those tiny little perfect companies you mention and we&#39;d
    all like to have.<span><br>
    <blockquote>
      <p dir=3D"ltr">&gt; Why do people think Bjarne &amp; Co keep pushing
        for language features that make people write &quot;good code by
        default&quot;? Because right now it is way too easy to write bad co=
de
        by default.</p>
      <p dir=3D"ltr">So you propose to... make it even easier to write bad
        code by default? At least currently code depending on evaluation
        order can be detected when it breaks. </p>
    </blockquote></span>
    WTF? The code is only bad because it depends on something that is
    undefined. If the order *is* defined it&#39;s no longer bad (certainly
    not world-breaking bad). It&#39;s really fascinating how the associatio=
n
    to bad code is upheld even if the conditions that make the code bad
    in the first place no longer existed. It used to be bad code to
    return objects by value but now that we have moves the cause for the
    bad code is gone and it is now considered good code, and it&#39;s still
    difficult for people to grasp and adapt who have avoided such code
    like the plague for 20+ years. Best practices change along changes
    to the language and library.<br>
    <br>
    It &quot;can&quot; be detecten when it breaks, sure. Maybe. If the plan=
ets are
    aligned so your compiler has a bad day. Or maybe the bug doesn&#39;t
    surface for years and then, suddenly, disaster. That&#39;s the whole
    point of this discussion. Bugs which cannot be deterministically
    reproduced on every developer&#39;s machine are the worst kind of bugs.
    Even worse is not knowing there is a bug at all until it&#39;s too late=
..<br>
    <br>
    So far the side opposing a fixed order of evaluation has failed to
    provide any examples that clearly demonstrate where unspecified
    order of evaluation is deliberately intended by the author, and
    important to the correctness or the efficiency of the code, bar some
    toy examples. All the arguments put forth so far go along the line
    of &quot;don&#39;t be a scrub you fool and don&#39;t make mistakes&quot=
;. That is a
    very elitist stance to have. Is that what the C++ community is these
    days? A bunch of decade-long experts who don&#39;t want to make changes
    to the language because, really, you just have to &quot;get good&quot;,
    regardless how difficult that is for apprentices. Can&#39;t have
    newcomers have it easier than we did, right? Is that what we&#39;re
    going to teach students now? &quot;Just don&#39;t make mistakes and you=
&#39;ll be
    fine, oh and make sure to study this 1300 pages standardese document
    so you know all the rules and edge cases, and don&#39;t you dare forget
    a single rule lest you be considered a bad programmer&quot;.<br>
    <br>
  </div><span>


<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
eyIfhf2zBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;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"eyIfhf2zBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;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/56DC51D0.2010501%40gmail.com?utm_medi=
um=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/56DC51D0.2010501%40gmail.com?utm_medium\75email\46utm_source\=
75footer&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/56DC51D0.2010501%40gmail.com?utm_=
medium\75email\46utm_source\75footer&#39;;return true;">https://groups.goog=
le.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/56DC51D</a></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7e6b6b4c-3e2f-4240-b460-221d5d46fb41%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7e6b6b4c-3e2f-4240-b460-221d5d46fb41=
%40isocpp.org</a>.<br />

------=_Part_218_806084939.1457455713669--
------=_Part_217_1979941167.1457455713668--

.

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

On Tue, Mar 8, 2016 at 11:48 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> (Alternatives? Hmm... still ugly like C#'s scoped "using" if the right
> operand is used more than once and locality is wanted:)
>

Ada got it right (of course).  Ada has boolean binary operators 'and' and
'or' which evaluate both sides and may be overloaded.  It also has
short-circuiting forms 'and then' and 'or else' which cannot be overloaded.

As far as a cascade of pointers go, stop trying to be compact:

auto p = ...
if (p) {
    auto q = p->...;
    if (q) {
        auto r  = q->...
        if (r) {
            r->...
        }
    }
}

--
You received this message because you are 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/CAHSYqdayFZUDKFuOA88K7fCfAgitAriiwcWCZK357SqMRgXiHQ%40mail.gmail.com.

--001a1143f154b2facf052d8c9e4c
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, Mar 8, 2016 at 11:48 AM, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&gt=
;</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>(Altern=
atives? Hmm... still ugly like C#&#39;s scoped &quot;using&quot; if the rig=
ht operand is used more than once and locality is wanted:)</div></div></blo=
ckquote><div><br>Ada got it right (of course).=C2=A0 Ada has boolean binary=
 operators &#39;and&#39; and &#39;or&#39; which evaluate both sides and may=
 be overloaded.=C2=A0 It also has short-circuiting forms &#39;and then&#39;=
 and &#39;or else&#39; which cannot be overloaded.<br><br>As far as a casca=
de of pointers go, stop trying to be compact:<br><br>auto p =3D ...<br>if (=
p) {<br>=C2=A0 =C2=A0 auto q =3D p-&gt;...;<br>=C2=A0 =C2=A0 if (q) {<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto r =C2=A0=3D q-&gt;...<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 if (r) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r-&=
gt;...</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 }</d=
iv><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdayFZUDKFuOA88K7fCfAgitAriiwcWC=
ZK357SqMRgXiHQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdayFZUDKFuO=
A88K7fCfAgitAriiwcWCZK357SqMRgXiHQ%40mail.gmail.com</a>.<br />

--001a1143f154b2facf052d8c9e4c--

.

------=_Part_7273_60165723.1457457056772
Content-Type: multipart/alternative;
 boundary="----=_Part_7274_1694889181.1457457056773"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8A=E5=8D=881:43:26=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 06.03.2016 um 17:43 schrieb Patrice Roy:=20
> > I know people take this issue to heart, but I think it would be=20
> > preferable for the debate if we collectively kept wording =C2=ABcalmed =
down=C2=BB.=20
> >=20
> > There are C++ idioms based on evaluation order, such as =C2=ABif (p &&=
=20
> > p->f()) for some pointer p that checks whether it's null before using=
=20
> > it. I doubt anyone would claim that such idioms are =C2=ABa bad thing=
=C2=BB as=20
> > they are integrated in practice and have been for decades. It becomes=
=20
> > annoying when someone overloads operator&& but apart from this, it=20
> > works well and sets a nice precedent of code relying on evaluation=20
> > order. There are others, of course, particularly with respect to=20
> > operators.=20
> >=20
> > I think the point that some have made that they feel f(g(), h())=20
> > should have a well-defined order for g() and h() is clear. I don't=20
> > have to agree with it but it's a clear point, and we'll most probably=
=20
> > hear it in the discussions we'll have in Oulu as the proposal for=20
> > evaluation order should be brought up there. Maybe it will convince=20
> > people better than it convinced me, we'll see. I have never seen the=20
> > undefined ordering of g() and h() in such a case as expert-level=20
> > knowledge (most of my students, if not all, learn that from the=20
> > start), but I believe those who say their experience differs.=20
> Unfortunately we cannot ensure all students are tought the same things=20
> and come out of college with the same level of knowledge. I believe the=
=20
> fewer rules there are they have to remember the more time and brainpower=
=20
> they have available to solve the actual problem instead of fighting the=
=20
> language, making the whole learning process less frustrating and more=20
> enjoyable.=20
>
If you want fewer rules, you'd prefer unspecified order rules than proposed=
=20
wording.

>=20
> > I understand the potential efficiency loss argument with respect to=20
> > the current undefined ordering. I'd need to see numbers, though, to be=
=20
> > convinced. If we get [[pure]], this argument will be strengthened a=20
> > bit (we could not evaluate sume functions that have been memoized, for=
=20
> > example), but that's an =C2=ABif=C2=BB.=20
> >=20
> > The fact that depending on this newly-defined order risks becoming=20
> > idiomatic is what worries me, and many others. As stated previously,=20
> > this would make such things as f(i++,i++) acceptable practice with=20
> > respect to the standard (even if not according to many coding=20
> > standards) given that operator++(int) can be overloaded.=20
> I don't understand the worry. As you have stated yourself, depending on=
=20
> "if(p && p->f())" is considered OK, but why? Because it *is* OK or=20
> because it has been done for decades and people got used to it?

Nope. This is a classic comprise about weakness of type system and some=20
other subtle rules.
=20

> The=20
> current proposal suggests overloaded operators to get the same order as=
=20
> the builtin ones, so that trap would go away. "f(g(), h())" is currently=
=20
> bad because it is undefined and nondeterministic, but if that changes=20
> and it *is* defined and deterministic, why is it still bad?

Because the change of rules itself is bad. There would be no way to express=
=20
nondeterminstic evaluation, which is intended sometimes.
=20

> If the root=20
> cause for the badness is removed, what makes it still bad? I seriously=20
> don't understand the line of thought. If, as you say below, students=20
> intuitively follow this idiom in C# because they realize it is=20
> well-defined, isn't that a sign it is what people actually want to do?=20
> So why is it still considered a problem und the new rules?=20
>
> Is this maybe just a "fear of the new"? Is this new idiom "unwanted"=20
> because it contradicts what has been ingrained into our brains over so=20
> many years and suddenly that instinct is at risk of becoming obsolete?=20
> To paraphrase Bjarne: people first want new features to have verbose=20
> syntax, be explicit, and stand out, but once they get used to them they=
=20
> want terse and convenient syntax instead. Is this worry based on the=20
> same psychological effect?=20
>
> In other words: is the opposition to writing such code (after the=20
> appropriate language change) based on objective facts or subjective=20
> (maybe subconcious) fears?=20
>
> I am genuinly interested in the reasoning because if there are good=20
> technical or psychological reasons against the idiom you describe I want=
=20
> to know them.=20
>
> A reason I see in favor of the idiom is the fact the compiler can more=20
> efficiently treat the temporaries in a case like "f(g(), h())" without=20
> me having to do anything special. If people have to sequence the=20
> expression with statements they have to litter their code with std::move=
=20
> to give it the same semantics as the compiler would have done by=20
> default, and you are forced to introduce single-use variables into your=
=20
> code, which may be a help or hindrance depending on circumstance.=20
>
> So in order to manually sequence the expression=20
> f(g(), h())=20
>
> I have to write=20
> auto a =3D g();=20
> auto b =3D h();=20
> f(std::move(a), std::move(b))=20
>
> Use auto&&, please, though naming might be still a problem. I personally=
=20
like f(g(); h()).
=20

> The compiler has more freedom with prvalues than it has with xvalues and=
=20
> I can tell from experience that people often forget std::move. Without=20
> the move a reviewer has to ask themselves "is this copy deliberate or=20
> did they forget to move?". If evaluation order is well-defined then in=20
> the single-expression case there is nothing to forget ...

--=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/b6db3c7f-34d7-49cd-bd01-36212d8d3de1%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=881:43:26=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 06.=
03.2016 um 17:43 schrieb Patrice Roy:
<br>&gt; I know people take this issue to heart, but I think it would be=20
<br>&gt; preferable for the debate if we collectively kept wording =C2=ABca=
lmed down=C2=BB.
<br>&gt;
<br>&gt; There are C++ idioms based on evaluation order, such as =C2=ABif (=
p &amp;&amp;=20
<br>&gt; p-&gt;f()) for some pointer p that checks whether it&#39;s null be=
fore using=20
<br>&gt; it. I doubt anyone would claim that such idioms are =C2=ABa bad th=
ing=C2=BB as=20
<br>&gt; they are integrated in practice and have been for decades. It beco=
mes=20
<br>&gt; annoying when someone overloads operator&amp;&amp; but apart from =
this, it=20
<br>&gt; works well and sets a nice precedent of code relying on evaluation=
=20
<br>&gt; order. There are others, of course, particularly with respect to=
=20
<br>&gt; operators.
<br>&gt;
<br>&gt; I think the point that some have made that they feel f(g(), h())=
=20
<br>&gt; should have a well-defined order for g() and h() is clear. I don&#=
39;t=20
<br>&gt; have to agree with it but it&#39;s a clear point, and we&#39;ll mo=
st probably=20
<br>&gt; hear it in the discussions we&#39;ll have in Oulu as the proposal =
for=20
<br>&gt; evaluation order should be brought up there. Maybe it will convinc=
e=20
<br>&gt; people better than it convinced me, we&#39;ll see. I have never se=
en the=20
<br>&gt; undefined ordering of g() and h() in such a case as expert-level=
=20
<br>&gt; knowledge (most of my students, if not all, learn that from the=20
<br>&gt; start), but I believe those who say their experience differs.
<br>Unfortunately we cannot ensure all students are tought the same things=
=20
<br>and come out of college with the same level of knowledge. I believe the=
=20
<br>fewer rules there are they have to remember the more time and brainpowe=
r=20
<br>they have available to solve the actual problem instead of fighting the=
=20
<br>language, making the whole learning process less frustrating and more=
=20
<br>enjoyable.
<br></blockquote><div>If you want fewer rules, you&#39;d prefer unspecified=
 order rules than proposed wording.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">&gt;
<br>&gt; I understand the potential efficiency loss argument with respect t=
o=20
<br>&gt; the current undefined ordering. I&#39;d need to see numbers, thoug=
h, to be=20
<br>&gt; convinced. If we get [[pure]], this argument will be strengthened =
a=20
<br>&gt; bit (we could not evaluate sume functions that have been memoized,=
 for=20
<br>&gt; example), but that&#39;s an =C2=ABif=C2=BB.
<br>&gt;
<br>&gt; The fact that depending on this newly-defined order risks becoming=
=20
<br>&gt; idiomatic is what worries me, and many others. As stated previousl=
y,=20
<br>&gt; this would make such things as f(i++,i++) acceptable practice with=
=20
<br>&gt; respect to the standard (even if not according to many coding=20
<br>&gt; standards) given that operator++(int) can be overloaded.
<br>I don&#39;t understand the worry. As you have stated yourself, dependin=
g on=20
<br>&quot;if(p &amp;&amp; p-&gt;f())&quot; is considered OK, but why? Becau=
se it *is* OK or=20
<br>because it has been done for decades and people got used to it?</blockq=
uote><div>Nope. This is a classic comprise about weakness of type system an=
d some other subtle rules.<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;">The=20
<br>current proposal suggests overloaded operators to get the same order as=
=20
<br>the builtin ones, so that trap would go away. &quot;f(g(), h())&quot; i=
s currently=20
<br>bad because it is undefined and nondeterministic, but if that changes=
=20
<br>and it *is* defined and deterministic, why is it still bad?</blockquote=
><div>Because the change of rules itself is bad. There would be no way to e=
xpress nondeterminstic evaluation, which is intended sometimes.<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;">If the root=20
<br>cause for the badness is removed, what makes it still bad? I seriously=
=20
<br>don&#39;t understand the line of thought. If, as you say below, student=
s=20
<br>intuitively follow this idiom in C# because they realize it is=20
<br>well-defined, isn&#39;t that a sign it is what people actually want to =
do?=20
<br>So why is it still considered a problem und the new rules?
<br>
<br>Is this maybe just a &quot;fear of the new&quot;? Is this new idiom &qu=
ot;unwanted&quot;=20
<br>because it contradicts what has been ingrained into our brains over so=
=20
<br>many years and suddenly that instinct is at risk of becoming obsolete?=
=20
<br>To paraphrase Bjarne: people first want new features to have verbose=20
<br>syntax, be explicit, and stand out, but once they get used to them they=
=20
<br>want terse and convenient syntax instead. Is this worry based on the=20
<br>same psychological effect?
<br>
<br>In other words: is the opposition to writing such code (after the=20
<br>appropriate language change) based on objective facts or subjective=20
<br>(maybe subconcious) fears?
<br>
<br>I am genuinly interested in the reasoning because if there are good=20
<br>technical or psychological reasons against the idiom you describe I wan=
t=20
<br>to know them.
<br>
<br>A reason I see in favor of the idiom is the fact the compiler can more=
=20
<br>efficiently treat the temporaries in a case like &quot;f(g(), h())&quot=
; without=20
<br>me having to do anything special. If people have to sequence the=20
<br>expression with statements they have to litter their code with std::mov=
e=20
<br>to give it the same semantics as the compiler would have done by=20
<br>default, and you are forced to introduce single-use variables into your=
=20
<br>code, which may be a help or hindrance depending on circumstance.
<br>
<br>So in order to manually sequence the expression
<br>f(g(), h())
<br>
<br>I have to write
<br>auto a =3D g();
<br>auto b =3D h();
<br>f(std::move(a), std::move(b))
<br>
<br></blockquote><div>Use auto&amp;&amp;, please, though naming might be st=
ill a problem. I personally like f(g(); h()).<br>=C2=A0<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">The compiler has more freedom with prval=
ues than it has with xvalues and=20
<br>I can tell from experience that people often forget std::move. Without=
=20
<br>the move a reviewer has to ask themselves &quot;is this copy deliberate=
 or=20
<br>did they forget to move?&quot;. If evaluation order is well-defined the=
n in=20
<br>the single-expression case there is nothing to forget ...</blockquote><=
/div>

<p></p>

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

------=_Part_7274_1694889181.1457457056773--
------=_Part_7273_60165723.1457457056772--

.

------=_Part_7292_1607733922.1457457708558
Content-Type: multipart/alternative;
 boundary="----=_Part_7293_1336617964.1457457708559"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8A=E5=8D=886:28:15=EF=BC=8CMichi Henning=E5=86=99=E9=81=93=EF=BC=9A
>
>
> Defining evaluation order cannot break an existing correct program, only=
=20
> an existing incorrect one.=20
>
> Defining evaluation order *would *break existing *code *because it will=
=20
likely alter the semantic representation of a program which may be=20
unexpected. Only the behavior of a well-formed and well-defined program are=
=20
guaranteed to be not changed when translated by conforming implementations.

Note: I am not necessarily the end user. I care more than the program=20
behavior.

--=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/54af7c79-e6d9-4c1b-a5e4-2f2981a96b5a%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=886:28:15=EF=BC=8CMichi Henning=
=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;">
<br>Defining evaluation order cannot break an existing correct program, onl=
y an existing incorrect one.
<br>
<br></blockquote><div>Defining evaluation order <i>would </i>break existing=
 <i>code </i>because it will likely alter the semantic representation of a =
program which may be unexpected. Only the behavior of a well-formed and wel=
l-defined program are guaranteed to be not changed when translated by confo=
rming implementations.<br><br>Note: I am not necessarily the end user. I ca=
re more than the program behavior.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/54af7c79-e6d9-4c1b-a5e4-2f2981a96b5a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/54af7c79-e6d9-4c1b-a5e4-2f2981a96b5a=
%40isocpp.org</a>.<br />

------=_Part_7293_1336617964.1457457708559--
------=_Part_7292_1607733922.1457457708558--

.

On 2016-03-08 12:21, FrankHB1989 wrote:
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UT=
C+8=E4=B8=8A=E5=8D=886:28:15=EF=BC=8CMichi Henning=E5=86=99=E9=81=93=EF=BC=
=9A
>> Defining evaluation order cannot break an existing correct program, only=
=20
>> an existing incorrect one.=20
>
> Defining evaluation order *would break existing code* because it will=20
> likely alter the semantic representation of a program which may be=20
> unexpected. Only the behavior of a well-formed and well-defined program a=
re=20
> guaranteed to be not changed when translated by conforming implementation=
s.

Yes, and Michi Henning did specify *correct* existing code. Any program
that the change breaks *was already broken*.

--=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/nbn2fs%24hpb%241%40ger.gmane.org.

.

This is a multi-part message in MIME format.
--------------070509010404030404080904
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Am 08.03.2016 um 18:10 schrieb FrankHB1989:
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UT=
C+8=E4=B8=8A=E5=8D=881:43:26=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
>     Am 06.03.2016 um 17:43 schrieb Patrice Roy:
>     > I know people take this issue to heart, but I think it would be
>     > preferable for the debate if we collectively kept wording
>     =C2=ABcalmed down=C2=BB.
>     >
>     > There are C++ idioms based on evaluation order, such as =C2=ABif (p=
 &&
>     > p->f()) for some pointer p that checks whether it's null before
>     using
>     > it. I doubt anyone would claim that such idioms are =C2=ABa bad
>     thing=C2=BB as
>     > they are integrated in practice and have been for decades. It
>     becomes
>     > annoying when someone overloads operator&& but apart from this, it
>     > works well and sets a nice precedent of code relying on evaluation
>     > order. There are others, of course, particularly with respect to
>     > operators.
>     >
>     > I think the point that some have made that they feel f(g(), h())
>     > should have a well-defined order for g() and h() is clear. I don't
>     > have to agree with it but it's a clear point, and we'll most
>     probably
>     > hear it in the discussions we'll have in Oulu as the proposal for
>     > evaluation order should be brought up there. Maybe it will convince
>     > people better than it convinced me, we'll see. I have never seen
>     the
>     > undefined ordering of g() and h() in such a case as expert-level
>     > knowledge (most of my students, if not all, learn that from the
>     > start), but I believe those who say their experience differs.
>     Unfortunately we cannot ensure all students are tought the same
>     things
>     and come out of college with the same level of knowledge. I
>     believe the
>     fewer rules there are they have to remember the more time and
>     brainpower
>     they have available to solve the actual problem instead of
>     fighting the
>     language, making the whole learning process less frustrating and more
>     enjoyable.
>
> If you want fewer rules, you'd prefer unspecified order rules than=20
> proposed wording.
>
>     >
>     > I understand the potential efficiency loss argument with respect to
>     > the current undefined ordering. I'd need to see numbers, though,
>     to be
>     > convinced. If we get [[pure]], this argument will be strengthened a
>     > bit (we could not evaluate sume functions that have been
>     memoized, for
>     > example), but that's an =C2=ABif=C2=BB.
>     >
>     > The fact that depending on this newly-defined order risks becoming
>     > idiomatic is what worries me, and many others. As stated
>     previously,
>     > this would make such things as f(i++,i++) acceptable practice with
>     > respect to the standard (even if not according to many coding
>     > standards) given that operator++(int) can be overloaded.
>     I don't understand the worry. As you have stated yourself,
>     depending on
>     "if(p && p->f())" is considered OK, but why? Because it *is* OK or
>     because it has been done for decades and people got used to it?
>
> Nope. This is a classic comprise about weakness of type system and=20
> some other subtle rules.
>
>     The
>     current proposal suggests overloaded operators to get the same
>     order as
>     the builtin ones, so that trap would go away. "f(g(), h())" is
>     currently
>     bad because it is undefined and nondeterministic, but if that changes
>     and it *is* defined and deterministic, why is it still bad?
>
> Because the change of rules itself is bad. There would be no way to=20
> express nondeterminstic evaluation, which is intended sometimes.
Please show an example where it is intended and why it is important that=20
it is nondeterministic.

--=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/56DF0EFA.5080104%40gmail.com.

--------------070509010404030404080904
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 08.03.2016 um 18:10 schrieb FrankHB1989:<br>
    <blockquote
      cite=3D"mid:b6db3c7f-34d7-49cd-bd01-36212d8d3de1@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=80 UTC+8=E4=B8=8A=E5=8D=881:43:26=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
          06.03.2016 um 17:43 schrieb Patrice Roy:
          <br>
          &gt; I know people take this issue to heart, but I think it
          would be <br>
          &gt; preferable for the debate if we collectively kept wording
          =C2=ABcalmed down=C2=BB.
          <br>
          &gt;
          <br>
          &gt; There are C++ idioms based on evaluation order, such as
          =C2=ABif (p &amp;&amp; <br>
          &gt; p-&gt;f()) for some pointer p that checks whether it's
          null before using <br>
          &gt; it. I doubt anyone would claim that such idioms are =C2=ABa
          bad thing=C2=BB as <br>
          &gt; they are integrated in practice and have been for
          decades. It becomes <br>
          &gt; annoying when someone overloads operator&amp;&amp; but
          apart from this, it <br>
          &gt; works well and sets a nice precedent of code relying on
          evaluation <br>
          &gt; order. There are others, of course, particularly with
          respect to <br>
          &gt; operators.
          <br>
          &gt;
          <br>
          &gt; I think the point that some have made that they feel
          f(g(), h()) <br>
          &gt; should have a well-defined order for g() and h() is
          clear. I don't <br>
          &gt; have to agree with it but it's a clear point, and we'll
          most probably <br>
          &gt; hear it in the discussions we'll have in Oulu as the
          proposal for <br>
          &gt; evaluation order should be brought up there. Maybe it
          will convince <br>
          &gt; people better than it convinced me, we'll see. I have
          never seen the <br>
          &gt; undefined ordering of g() and h() in such a case as
          expert-level <br>
          &gt; knowledge (most of my students, if not all, learn that
          from the <br>
          &gt; start), but I believe those who say their experience
          differs.
          <br>
          Unfortunately we cannot ensure all students are tought the
          same things <br>
          and come out of college with the same level of knowledge. I
          believe the <br>
          fewer rules there are they have to remember the more time and
          brainpower <br>
          they have available to solve the actual problem instead of
          fighting the <br>
          language, making the whole learning process less frustrating
          and more <br>
          enjoyable.
          <br>
        </blockquote>
        <div>If you want fewer rules, you'd prefer unspecified order
          rules than proposed wording.<br>
          <br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;
          <br>
          &gt; I understand the potential efficiency loss argument with
          respect to <br>
          &gt; the current undefined ordering. I'd need to see numbers,
          though, to be <br>
          &gt; convinced. If we get [[pure]], this argument will be
          strengthened a <br>
          &gt; bit (we could not evaluate sume functions that have been
          memoized, for <br>
          &gt; example), but that's an =C2=ABif=C2=BB.
          <br>
          &gt;
          <br>
          &gt; The fact that depending on this newly-defined order risks
          becoming <br>
          &gt; idiomatic is what worries me, and many others. As stated
          previously, <br>
          &gt; this would make such things as f(i++,i++) acceptable
          practice with <br>
          &gt; respect to the standard (even if not according to many
          coding <br>
          &gt; standards) given that operator++(int) can be overloaded.
          <br>
          I don't understand the worry. As you have stated yourself,
          depending on <br>
          "if(p &amp;&amp; p-&gt;f())" is considered OK, but why?
          Because it *is* OK or <br>
          because it has been done for decades and people got used to
          it?</blockquote>
        <div>Nope. This is a classic comprise about weakness of type
          system and some other subtle rules.<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;">The <br>
          current proposal suggests overloaded operators to get the same
          order as <br>
          the builtin ones, so that trap would go away. "f(g(), h())" is
          currently <br>
          bad because it is undefined and nondeterministic, but if that
          changes <br>
          and it *is* defined and deterministic, why is it still bad?</bloc=
kquote>
        <div>Because the change of rules itself is bad. There would be
          no way to express nondeterminstic evaluation, which is
          intended sometimes.<br>
        </div>
      </div>
    </blockquote>
    Please show an example where it is intended and why it is important
    that it is nondeterministic.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/56DF0EFA.5080104%40gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/ms=
gid/std-proposals/56DF0EFA.5080104%40gmail.com</a>.<br />

--------------070509010404030404080904--

.

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

On Tue, Mar 8, 2016 at 3:43 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
>
> What do you mean by that? That there's nothing wrong with young students
> being frustrated by C++ and not explore it further and instead join the
> crowd of ignorant developers who get a panic attack when hearing the word
> "pointer"? I want as many computer science students as possible to like and
> use C++ because that includes the understanding of the underlying machine
> interfaction engineering principles they may never learn in any of those
> fancy higher-level languages.
>

Pretending that the underlying machine executes instructions in serial
actively impedes computer science students' understanding, ignoring decades
of advances in processor technology: microcode, deep pipelines,
hyperthreading, speculative execution, dynamic execution etc. Simplifying
the machine model to make it easier to explain to students is not only
patronizing, it does those students a huge disservice.

On Tue, Mar 8, 2016 at 4:32 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> A computer program is the means whereby a computer is instructed to carry
> out a computation.  Allowing the meaning of parts of a program to be
> unspecified is a failure to provide specific instructions to the computer,
> and to the extent that the author of the program did not mean this lack of
> specificity, is a trap for the author and for all future users of the
> program.
>

The meaning is fully specified. The behavior may not be, but that is
irrelevant; a program that fully specifies behavior would be so inflexible
as to be 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/CAJnLdObuyF80GRWX6ZABswiXo2Wqzky2stODuh_OUHWgie0TZQ%40mail.gmail.com.

--001a113ecbe44dc04e052d8d3391
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, Mar 8, 2016 at 3:43 PM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</s=
pan> 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);border-left-st=
yle:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    What do you mean by that? That there&#39;s nothing wrong with young
    students being frustrated by C++ and not explore it further and
    instead join the crowd of ignorant developers who get a panic attack
    when hearing the word &quot;pointer&quot;? I want as many computer scie=
nce
    students as possible to like and use C++ because that includes the
    understanding of the underlying machine interfaction engineering
    principles they may never learn in any of those fancy higher-level
    languages.<br></div></blockquote><div><br></div><div>Pretending that th=
e underlying machine executes instructions in serial actively impedes compu=
ter science students&#39; understanding, ignoring decades of advances in pr=
ocessor technology: microcode, deep pipelines, hyperthreading, speculative =
execution, dynamic execution etc. Simplifying the machine model to make it =
easier to explain to students is not only patronizing, it does those studen=
ts a huge disservice.</div><div><br></div><div>On Tue, Mar 8, 2016 at 4:32 =
PM, Hyman Rosen=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:hyman.rosen@gm=
ail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt;</span>=C2=A0wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr">A computer program is the means where=
by a computer is instructed to carry out a computation.=C2=A0 Allowing the =
meaning of parts of a program to be unspecified is a failure to provide spe=
cific instructions to the computer, and to the extent that the author of th=
e program did not mean this lack of specificity, is a trap for the author a=
nd for all future users of the program.</div></blockquote></div><div><br></=
div><div>The meaning is fully specified. The behavior may not be, but that =
is irrelevant; a program that fully specifies behavior would be so inflexib=
le as to be useless.=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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObuyF80GRWX6ZABswiXo2Wqzky2stOD=
uh_OUHWgie0TZQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObuyF80GRWX=
6ZABswiXo2Wqzky2stODuh_OUHWgie0TZQ%40mail.gmail.com</a>.<br />

--001a113ecbe44dc04e052d8d3391--

.

------=_Part_2872_1582830873.1457460763435
Content-Type: multipart/alternative;
 boundary="----=_Part_2873_260930291.1457460763436"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8B=E5=8D=8811:13:53=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 08.03.2016 um 13:00 schrieb FrankHB1989:
>
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8A=E5=8D=889:06:46=EF=BC=8CMichi Henning=E5=86=99=E9=81=93=EF=BC=
=9A=20
>
> They didn't forget. They seem to have deliberately left it unspecified.
>
> Source: https://www.eskimo.com/~scs/cclass/notes/sx7c.html
>
> quote: The moral is that writing code that depends on order of evaluation=
=20
> is a bad programming practice in any language. Naturally, it is necessary=
=20
> to know what things to avoid, but if you don't know *how* they are done=
=20
> on various machines, you won't be tempted to take advantage of a particul=
ar=20
> implementation.=20
>
>
> I just dug out my 1st edition copy of K&R and, yes, those words are indee=
d=20
> there (final para on page 50).
>
> To state that =E2=80=9Cwriting code that depends on order of evaluation i=
s bad=20
> programming practice in any language=E2=80=9D is to make a rather sweepin=
g=20
> statement, and one that is contradicted by many modern languages. In K&R=
=E2=80=99s=20
> defense, the statement was made almost 40 years ago.
>
> We use sequencing all the time. If I write
>
> a =3D b;
> c +=3D 2 * a;
>
> I=E2=80=99d be rather surprised if the compiler were to re-order these tw=
o=20
> statements.
>
>
> Certainly not allowed. Semicolons has clear semantics to forbid this.
> =20
>
> But, for some reason I can=E2=80=99t quite follow, doing the same thing f=
or=20
> expressions is considered bad, even though a complex expression is just a=
=20
> sequence of simple statements. Why anyone would deem it desirable for=20
> things to be evaluated in any order is beyond me, hypothetical compile-ti=
me=20
> optimizations notwithstanding.
>
> Things are just different for commas. It should be natural semicolons and=
=20
> commas are different, because they look different. If you want sequenced=
=20
> evaluation, use semicolons explicitly. This is clean, tidy and easy.
>
> The true bad thing is, whether a comma indicates sequenced evaluation or=
=20
> not is context-sensitive. It depends on whether it is an operator or not.=
=20
> This syntactic inconsistency is stupid, since it confuse peoples a lot, a=
nd=20
> the only usage is to overcome the fact of lacking of sequenced evaluation=
=20
> constructs in clauses of some statements. This is the limitation of=20
> standard C. Both expression statements and lambda expressions can work=20
> around it nicely, but as a consequence of that random design, (possibly=
=20
> insanely overloaded) "operator," remains painful in C++. Forcing=20
> left-to-right evaluation on function calls would eliminate the=20
> inconsistency between overloaded and builtin "operator,", however, also=
=20
> make the whole design of language uglier.
>
> Do you have a definition for "uglier"? As you say yourself, turning "this=
=20
> list of values is unorderd but this one is" into "all lists of values are=
=20
> ordered" makes the language more consistent. How is making the language=
=20
> more consistent making it "uglier"? Neurological psychology shows us agai=
n=20
> and again that people do better remembering and applying rules the fewer=
=20
> exceptions they have. T ...


I say it is uglier because there would be worse confusions. As effect on=20
evaluations, "," will likely considered to be a bad ";" or vice versa. So=
=20
why not replace all ';' to ','? Otherwise, why should people remember the=
=20
difference between ',' and ';'?

Oh, ',' is still not only a separator, it can also be a terminator (for=20
enumerators). The special cases have been weaved into the corners of the=20
syntax for a long time, so you cannot have simpler rules in general.

And forcing all evaluation ordered has nothing to do with consistency. It=
=20
is just disabled on expressing nondeterministic evaluations.

I can also argue that there are more than one orders and you have to choose=
=20
one randomly. LTR is actually a more explicit "exception". Why array=20
indices grow from 0 rather than 1? Why there is "zero"-initialization but=
=20
no "one"-initialization?
=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/46070965-9f11-405f-af8d-869394d492be%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=888=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8811:13:53=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
    Am 08.03.2016 um 13:00 schrieb FrankHB1989:<br>
    <blockquote>
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2016=E5=B9=B43=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=
=94 UTC+8=E4=B8=8A=E5=8D=889:06:46=EF=BC=8CMichi Henning=E5=86=99=E9=81=93=
=EF=BC=9A
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div style=3D"word-wrap:break-word">
            <div>
              <blockquote>
                <div>
                  <div dir=3D"ltr">
                    <div>
                      <div>
                        <div>They didn&#39;t forget. They seem to have
                          deliberately left it unspecified.</div>
                        <div><br>
                        </div>
                        <div>Source: <a href=3D"https://www.eskimo.com/%7Es=
cs/cclass/notes/sx7c.html" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fwww.eskim=
o.com%2F%257Escs%2Fcclass%2Fnotes%2Fsx7c.html\46sa\75D\46sntz\0751\46usg\75=
AFQjCNEJsRodjwCu1AGOTFwKhQ78ZZ1PoQ&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fwww.eskimo.com%2F%257E=
scs%2Fcclass%2Fnotes%2Fsx7c.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEJsRodj=
wCu1AGOTFwKhQ78ZZ1PoQ&#39;;return true;">https://www.eskimo.com/~scs/<wbr>c=
class/notes/sx7c.html</a></div>
                        <div><br>
                        </div>
                        <div>quote:=C2=A0<font color=3D"#ff0000"><span>The =
moral is
                              that writing code that depends on order of
                              evaluation is a bad programming practice
                              in any language. Naturally, it is
                              necessary to know what things to avoid,
                              but if you don&#39;t know=C2=A0</span><i>how<=
/i><span>=C2=A0they are done
                              on various machines, you won&#39;t be tempted
                              to take advantage of a particular
                              implementation.</span>=C2=A0</font></div>
                      </div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <div><br>
              </div>
              I just dug out my 1st edition copy of K&amp;R and, yes,
              those words are indeed there (final para on page 50).</div>
            <div><br>
            </div>
            <div>To state that =E2=80=9Cwriting code that depends on order =
of
              evaluation is bad programming practice in any language=E2=80=
=9D is
              to make a rather sweeping statement, and one that is
              contradicted by many modern languages. In K&amp;R=E2=80=99s
              defense, the statement was made almost 40 years ago.</div>
            <div><br>
            </div>
            <div>We use sequencing all the time. If I write</div>
            <div><br>
            </div>
            <div>a =3D b;</div>
            <div>c +=3D 2 * a;</div>
            <div><br>
            </div>
            <div>I=E2=80=99d be rather surprised if the compiler were to
              re-order these two statements.</div>
          </div>
        </blockquote>
        <div><br>
          Certainly not allowed. Semicolons has clear semantics to
          forbid this.<br>
          =C2=A0<br>
        </div>
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div style=3D"word-wrap:break-word">
            <div>But, for some reason I can=E2=80=99t quite follow, doing t=
he
              same thing for expressions is considered bad, even though
              a complex expression is just a sequence of simple
              statements. Why anyone would deem it desirable for things
              to be evaluated in any order is beyond me, hypothetical
              compile-time optimizations notwithstanding.</div>
            <div><br>
            </div>
          </div>
        </blockquote>
        <div>Things are just different for commas. It should be natural
          semicolons and commas are different, because they look
          different. If you want sequenced evaluation, use semicolons
          explicitly. This is clean, tidy and easy.<br>
          <br>
          The true bad thing is, whether a comma indicates sequenced
          evaluation or not is context-sensitive. It depends on whether
          it is an operator or not. This syntactic inconsistency is
          stupid, since it confuse peoples a lot, and the only usage is
          to overcome the fact of lacking of sequenced evaluation
          constructs in clauses of some statements. This is the
          limitation of standard C. Both expression statements and
          lambda expressions can work around it nicely, but as a
          consequence of that random design, (possibly insanely
          overloaded) &quot;operator,&quot; remains painful in C++. Forcing
          left-to-right evaluation on function calls would eliminate the
          inconsistency between overloaded and builtin &quot;operator,&quot=
;,
          however, also make the whole design of language uglier.</div>
      </div>
    </blockquote>
    Do you have a definition for &quot;uglier&quot;? As you say yourself, t=
urning
    &quot;this list of values is unorderd but this one is&quot; into &quot;=
all lists of
    values are ordered&quot; makes the language more consistent. How is
    making the language more consistent making it &quot;uglier&quot;? Neuro=
logical
    psychology shows us again and again that people do better
    remembering and applying rules the fewer exceptions they have. T  ...</=
blockquote><div><br>I say it is uglier because there would be worse confusi=
ons. As effect on evaluations, &quot;,&quot; will likely considered to be a=
 bad &quot;;&quot; or vice versa. So why not replace all &#39;;&#39; to &#3=
9;,&#39;? Otherwise, why should people remember the difference between &#39=
;,&#39; and &#39;;&#39;?<br><br>Oh, &#39;,&#39; is still not only a separat=
or, it can also be a terminator (for enumerators). The special cases have b=
een weaved into the corners of the syntax for a long time, so you cannot ha=
ve simpler rules in general.<br><br>And forcing all evaluation ordered has =
nothing to do with consistency. It is just disabled on expressing nondeterm=
inistic evaluations.<br><br>I can also argue that there are more than one o=
rders and you have to choose one randomly. LTR is actually a more explicit =
&quot;exception&quot;. Why array indices grow from 0 rather than 1? Why the=
re is &quot;zero&quot;-initialization but no &quot;one&quot;-initialization=
?<br>=C2=A0<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/46070965-9f11-405f-af8d-869394d492be%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/46070965-9f11-405f-af8d-869394d492be=
%40isocpp.org</a>.<br />

------=_Part_2873_260930291.1457460763436--
------=_Part_2872_1582830873.1457460763435--

.

This is a multi-part message in MIME format.
--------------070706030204020105070902
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 08.03.2016 um 18:49 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
> On Tue, Mar 8, 2016 at 3:43 PM, Miro Knejp <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
>
>     What do you mean by that? That there's nothing wrong with young
>     students being frustrated by C++ and not explore it further and
>     instead join the crowd of ignorant developers who get a panic
>     attack when hearing the word "pointer"? I want as many computer
>     science students as possible to like and use C++ because that
>     includes the understanding of the underlying machine interfaction
>     engineering principles they may never learn in any of those fancy
>     higher-level languages.
>
>
> Pretending that the underlying machine executes instructions in serial
> actively impedes computer science students' understanding, ignoring
> decades of advances in processor technology: microcode, deep
> pipelines, hyperthreading, speculative execution, dynamic execution
> etc. Simplifying the machine model to make it easier to explain to
> students is not only patronizing, it does those students a huge
> disservice.
Now you're putting words in my mouth. I didn't say anything about the
machine executing in serial order, or simplifying the machine model.
This is about how the compiler feeds the machine our code. Following
your logic saying "f(); g();" executes in serial order is doing the same
disservice. What I said is if we never get students to use a language
that is so close to the metal as C++ they have a much lower motivation
to learn about those principles.

--
You received this message because you are 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/56DF2065.4080107%40gmail.com.

--------------070706030204020105070902
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 08.03.2016 um 18:49 schrieb 'Edward Catmur' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CAJnLdObuyF80GRWX6ZABswiXo2Wqzky2stODuh_OUHWgie0TZQ@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">On Tue, Mar 8, 2016 at 3:43 PM, Miro
            Knejp <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro=
..knejp@gmail.com</a>&gt;</span>
            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);border-left-=
style:solid;padding-left:1ex">
              <div bgcolor=3D"#FFFFFF" text=3D"#000000"> What do you mean b=
y
                that? That there's nothing wrong with young students
                being frustrated by C++ and not explore it further and
                instead join the crowd of ignorant developers who get a
                panic attack when hearing the word "pointer"? I want as
                many computer science students as possible to like and
                use C++ because that includes the understanding of the
                underlying machine interfaction engineering principles
                they may never learn in any of those fancy higher-level
                languages.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Pretending that the underlying machine executes
              instructions in serial actively impedes computer science
              students' understanding, ignoring decades of advances in
              processor technology: microcode, deep pipelines,
              hyperthreading, speculative execution, dynamic execution
              etc. Simplifying the machine model to make it easier to
              explain to students is not only patronizing, it does those
              students a huge disservice.</div>
          </div>
        </div>
      </div>
    </blockquote>
    Now you're putting words in my mouth. I didn't say anything about
    the machine executing in serial order, or simplifying the machine
    model. This is about how the compiler feeds the machine our code.
    Following your logic saying "f(); g();" executes in serial order is
    doing the same disservice. What I said is if we never get students
    to use a language that is so close to the metal as C++ they have a
    much lower motivation to learn about those principles.<br>
  </body>
</html>

<p></p>

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

--------------070706030204020105070902--

.

--089e012955ec7d1fe0052d8e41b4
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 7, 2016 at 8:37 AM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Mon, Mar 7, 2016 at 11:15 AM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>
>> So, out of order evaluation is bad when you don't want it, but good when
>> you do want it???
>>
>
> C++ has three expression forms (&&, ||, ?:) in which some subexpressions
> may remain unevaluated, and two of these may be overloaded but in a way
> that does not preserve those evaluation semantics.  That is terribly bad.
> If we want to have overloads that preserve the language semantics, and we
> want overloads to be written in the form of function calls, then the
> functions must be given control over whether and when their arguments are
> evaluated.
>

While I understand where you are going, pointing to && and || isn't as
compelling as you might think. Though it's true that the left operand will
be evaluated before the right operand in these cases, the right operand may
not even be evaluated at all because of short-circuiting. *This* is the big
subtlety that people face when overloading || and &&. Forcing argument
evaluation order for overloads of those operators doesn't change that. In
other words, in a world where C++ defined left-to-right order from the
start, we would still have the caveat "overloads of || and && cannot
short-circuit", and I don't think that stating the left operand evaluates
before the right one gains much if anything here when compared to any other
function.

Also, for completeness, comma is another operator that evaluates the left
operand before the right one. It doesn't short-circuit, so it might be a
better comparison here (playing devil's advocate as I'm in favor of leaving
evaluation order as-is).

--
You received this message because you are 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/CANh8DEnbbbxSJucR165uTYjTYMxEeck5dqBd7FPteQw5cf0cFw%40mail.gmail.com.

--089e012955ec7d1fe0052d8e41b4
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, Mar 7, 2016 at 8:37 AM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@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);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><span class=3D"">On Mon, Mar 7, 2016 at 11:1=
5 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlor=
d.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><div>So, out of order evaluation is bad when you don&#39;t want =
it, but good when you do want it???</div></div></div></div></blockquote><di=
v>=C2=A0</div></span><div>C++ has three expression forms (&amp;&amp;, ||, ?=
:) in which some subexpressions may remain unevaluated, and two of these ma=
y be overloaded but in a way that does not preserve those evaluation semant=
ics.=C2=A0 That is terribly bad.=C2=A0 If we want to have overloads that pr=
eserve the language semantics, and we want overloads to be written in the f=
orm of function calls, then the functions must be given control over whethe=
r and when their arguments are evaluated.</div></div></div></div></blockquo=
te><div><br></div><div>While I understand where you are going, pointing to =
&amp;&amp; and || isn&#39;t as compelling as you might think. Though it&#39=
;s true that the left operand will be evaluated before the right operand in=
 these cases, the right operand may not even be evaluated at all because of=
 short-circuiting. <i>This</i> is the big subtlety that people face when ov=
erloading || and &amp;&amp;. Forcing argument evaluation order for overload=
s of those operators doesn&#39;t change that. In other words, in a world wh=
ere C++ defined left-to-right order from the start, we would still have the=
 caveat &quot;overloads of || and &amp;&amp; cannot short-circuit&quot;, an=
d I don&#39;t think that stating the left operand evaluates before the righ=
t one gains much if anything here when compared to any other function.</div=
><div><br></div><div>Also, for completeness, comma is another operator that=
 evaluates the left operand before the right one. It doesn&#39;t short-circ=
uit, so it might be a better comparison here (playing devil&#39;s advocate =
as I&#39;m in favor of leaving evaluation order as-is).</div></div><br></di=
v></div>

<p></p>

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

--089e012955ec7d1fe0052d8e41b4--

.

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

On Tue, Mar 8, 2016 at 2:04 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Mon, Mar 7, 2016 at 8:37 AM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>
>> On Mon, Mar 7, 2016 at 11:15 AM, Nevin Liber <nevin@eviloverlord.com>
>> wrote:
>>
>>> So, out of order evaluation is bad when you don't want it, but good when
>>> you do want it???
>>>
>>
>> C++ has three expression forms (&&, ||, ?:) in which some subexpressions
>> may remain unevaluated, and two of these may be overloaded but in a way
>> that does not preserve those evaluation semantics.  That is terribly bad.
>> If we want to have overloads that preserve the language semantics, and we
>> want overloads to be written in the form of function calls, then the
>> functions must be given control over whether and when their arguments are
>> evaluated.
>>
>
> While I understand where you are going, pointing to && and || isn't as
> compelling as you might think. Though it's true that the left operand will
> be evaluated before the right operand in these cases, the right operand may
> not even be evaluated at all because of short-circuiting. *This* is the
> big subtlety that people face when overloading || and &&. Forcing argument
> evaluation order for overloads of those operators doesn't change that. In
> other words, in a world where C++ defined left-to-right order from the
> start, we would still have the caveat "overloads of || and && cannot
> short-circuit", and I don't think that stating the left operand evaluates
> before the right one gains much if anything here when compared to any other
> function.
>

My point about && and || is that allowing overloading of them without
maintaining the short-circuit semantics is bad, and I have a notion of
introducing a version of call-by-name into C++ so that functions can
optionally evaluate their arguments, which would allow these overloaded
operators to also do the short-circuiting.  But once you have call-by-name,
functions with multiple by-name parameters can evaluate their arguments in
any order they choose, and this ability is supposed to indicate that I am
inconsistent in my desire for strict left-to-right evaluation order.


> Also, for completeness, comma is another operator that evaluates the left
> operand before the right one. It doesn't short-circuit, so it might be a
> better comparison here (playing devil's advocate as I'm in favor of leaving
> evaluation order as-is).
>

Oh, yes, of course.  Overloading comma has the ordering problem, but not
the short-circuiting problem, so it is just barely a lesser evil.

--
You received this message because you are 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/CAHSYqdbaxjDJ5utqZ3htGtxeUA9ddTzvtVeTxPXBwAR0UusOWw%40mail.gmail.com.

--001a114783cc10e3e1052d8e742f
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, Mar 8, 2016 at 2:04 PM, &#39;Matt Calabrese&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<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"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><span class=3D"">On Mon, Mar 7, 2016 at 8:37 A=
M, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"mailto:hyman.rosen@gmail.co=
m" target=3D"_blank">hyman.rosen@gmail.com</a>&gt;</span> wrote:<br><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"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><span>On Mon, Mar 7, 2016 at 11:15 AM, Nevin Liber <span dir=3D"ltr">=
&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilo=
verlord.com</a>&gt;</span> wrote:<br><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"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><div>So, out of order eva=
luation is bad when you don&#39;t want it, but good when you do want it???<=
/div></div></div></div></blockquote><div>=C2=A0</div></span><div>C++ has th=
ree expression forms (&amp;&amp;, ||, ?:) in which some subexpressions may =
remain unevaluated, and two of these may be overloaded but in a way that do=
es not preserve those evaluation semantics.=C2=A0 That is terribly bad.=C2=
=A0 If we want to have overloads that preserve the language semantics, and =
we want overloads to be written in the form of function calls, then the fun=
ctions must be given control over whether and when their arguments are eval=
uated.</div></div></div></div></blockquote><div><br></div></span><div>While=
 I understand where you are going, pointing to &amp;&amp; and || isn&#39;t =
as compelling as you might think. Though it&#39;s true that the left operan=
d will be evaluated before the right operand in these cases, the right oper=
and may not even be evaluated at all because of short-circuiting. <i>This</=
i> is the big subtlety that people face when overloading || and &amp;&amp;.=
 Forcing argument evaluation order for overloads of those operators doesn&#=
39;t change that. In other words, in a world where C++ defined left-to-righ=
t order from the start, we would still have the caveat &quot;overloads of |=
| and &amp;&amp; cannot short-circuit&quot;, and I don&#39;t think that sta=
ting the left operand evaluates before the right one gains much if anything=
 here when compared to any other function.</div></div></div></div></blockqu=
ote><div><br></div><div>My point about &amp;&amp; and || is that allowing o=
verloading of them without maintaining the short-circuit semantics is bad, =
and I have a notion of introducing a version of call-by-name into C++ so th=
at functions can optionally evaluate their arguments, which would allow the=
se overloaded operators to also do the short-circuiting.=C2=A0 But once you=
 have call-by-name, functions with multiple by-name parameters can evaluate=
 their arguments in any order they choose, and this ability is supposed to =
indicate that I am inconsistent in my desire for strict left-to-right evalu=
ation order.</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 class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Also, f=
or completeness, comma is another operator that evaluates the left operand =
before the right one. It doesn&#39;t short-circuit, so it might be a better=
 comparison here (playing devil&#39;s advocate as I&#39;m in favor of leavi=
ng evaluation order as-is).</div></div></div></div></blockquote><div><br>Oh=
, yes, of course.=C2=A0 Overloading comma has the ordering problem, but not=
 the short-circuiting problem, so it is just barely a lesser evil.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbaxjDJ5utqZ3htGtxeUA9ddTzvtVeT=
xPXBwAR0UusOWw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbaxjDJ5utq=
Z3htGtxeUA9ddTzvtVeTxPXBwAR0UusOWw%40mail.gmail.com</a>.<br />

--001a114783cc10e3e1052d8e742f--

.

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

=E2=80=8BI know i am rushing. But....
=E2=80=8BWhy should the evaluation order not follow that of precedence and
associativity(considering ltr for the case of function call)?
lately I posted a well-known ancient example of UB regarding evaluation
sequence in a forum:

cout << x  <<"," << ++x << endl;

the first reply came from a novice claiming that he could see no UB!!!!
I mean when the AST is present, what reason should prevent the compiler
from following it in evaluating parameters?

regards,
FM.

2016-03-08 21:19 GMT+03:30 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org>:

> On Tue, Mar 8, 2016 at 3:43 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
>>
>> What do you mean by that? That there's nothing wrong with young students
>> being frustrated by C++ and not explore it further and instead join the
>> crowd of ignorant developers who get a panic attack when hearing the wor=
d
>> "pointer"? I want as many computer science students as possible to like =
and
>> use C++ because that includes the understanding of the underlying machin=
e
>> interfaction engineering principles they may never learn in any of those
>> fancy higher-level languages.
>>
>
> Pretending that the underlying machine executes instructions in serial
> actively impedes computer science students' understanding, ignoring decad=
es
> of advances in processor technology: microcode, deep pipelines,
> hyperthreading, speculative execution, dynamic execution etc. Simplifying
> the machine model to make it easier to explain to students is not only
> patronizing, it does those students a huge disservice.
>
> On Tue, Mar 8, 2016 at 4:32 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote=
:
>
>> A computer program is the means whereby a computer is instructed to carr=
y
>> out a computation.  Allowing the meaning of parts of a program to be
>> unspecified is a failure to provide specific instructions to the compute=
r,
>> and to the extent that the author of the program did not mean this lack =
of
>> specificity, is a trap for the author and for all future users of the
>> program.
>>
>
> The meaning is fully specified. The behavior may not be, but that is
> irrelevant; a program that fully specifies behavior would be so inflexibl=
e
> as to be 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/CAJnLdObuyF8=
0GRWX6ZABswiXo2Wqzky2stODuh_OUHWgie0TZQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObuyF=
80GRWX6ZABswiXo2Wqzky2stODuh_OUHWgie0TZQ%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>



--=20
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

--=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/CALDL7dEjuLEaQaB%3DA6ughoxdbB8LUsfPFsPFcbjs5J37G=
8ButQ%40mail.gmail.com.

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

<div dir=3D"rtl"><div dir=3D"ltr" class=3D"gmail_default" style=3D"font-fam=
ily:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8BI know i am=
 rushing. But....</div><div dir=3D"ltr" class=3D"gmail_default" style=3D"fo=
nt-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8BWhy s=
hould the evaluation order not follow that of precedence and associativity(=
considering ltr for the=C2=A0case of=C2=A0function call)?</div><div dir=3D"=
ltr" class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sa=
ns-serif;font-size:large">lately I posted a well-known ancient example of U=
B regarding evaluation sequence in a forum:</div><div dir=3D"ltr" class=3D"=
gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large"><br></div><div dir=3D"ltr" class=3D"gmail_default" style=3D"fon=
t-family:&#39;arial narrow&#39;,sans-serif;font-size:large">cout &lt;&lt; x=
 =C2=A0&lt;&lt;&quot;,&quot; &lt;&lt; ++x &lt;&lt; endl;</div><div dir=3D"l=
tr" class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,san=
s-serif;font-size:large"><br></div><div dir=3D"ltr" class=3D"gmail_default"=
 style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">th=
e first reply came from a novice claiming that he could see no UB!!!!</div>=
<div dir=3D"ltr" class=3D"gmail_default" style=3D"font-family:&#39;arial na=
rrow&#39;,sans-serif;font-size:large">I mean when the AST is present, what =
reason should prevent the compiler from following it in evaluating paramete=
rs?</div><div dir=3D"ltr" class=3D"gmail_default" style=3D"font-family:&#39=
;arial narrow&#39;,sans-serif;font-size:large"><br></div><div dir=3D"ltr" c=
lass=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-ser=
if;font-size:large">regards,</div><div dir=3D"ltr" class=3D"gmail_default" =
style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">FM.=
</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div =
dir=3D"ltr">2016-03-08 21:19 GMT+03:30 &#39;Edward Catmur&#39; via ISO C++ =
Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-pro=
posals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span=
>:</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"><span class=3D"">On Tue, Mar 8, 2016 at =
3:43 PM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"mailto:miro.knejp@gmai=
l.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</span> wrote:<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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    What do you mean by that? That there&#39;s nothing wrong with young
    students being frustrated by C++ and not explore it further and
    instead join the crowd of ignorant developers who get a panic attack
    when hearing the word &quot;pointer&quot;? I want as many computer scie=
nce
    students as possible to like and use C++ because that includes the
    understanding of the underlying machine interfaction engineering
    principles they may never learn in any of those fancy higher-level
    languages.<br></div></blockquote><div><br></div></span><div>Pretending =
that the underlying machine executes instructions in serial actively impede=
s computer science students&#39; understanding, ignoring decades of advance=
s in processor technology: microcode, deep pipelines, hyperthreading, specu=
lative execution, dynamic execution etc. Simplifying the machine model to m=
ake it easier to explain to students is not only patronizing, it does those=
 students a huge disservice.</div><span class=3D""><div><br></div><div>On T=
ue, Mar 8, 2016 at 4:32 PM, Hyman Rosen=C2=A0<span dir=3D"ltr">&lt;<a href=
=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</=
a>&gt;</span>=C2=A0wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">A computer p=
rogram is the means whereby a computer is instructed to carry out a computa=
tion.=C2=A0 Allowing the meaning of parts of a program to be unspecified is=
 a failure to provide specific instructions to the computer, and to the ext=
ent that the author of the program did not mean this lack of specificity, i=
s a trap for the author and for all future users of the program.</div></blo=
ckquote></div><div><br></div></span><div>The meaning is fully specified. Th=
e behavior may not be, but that is irrelevant; a program that fully specifi=
es behavior would be so inflexible as to be useless.=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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAJnLdObuyF80GRWX6ZABswiXo2Wqzky2stOD=
uh_OUHWgie0TZQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAJnLdObuyF80GRWX6ZABswiXo2Wqzky2stODuh_OUHWgie0TZQ%40mail.gmail.com</=
a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how am I suppos=
ed to end the twisted road of=C2=A0 your hair in such a dark night??<br>unl=
ess the candle of your face does shed some light upon my way!!!<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dEjuLEaQaB%3DA6ughoxdbB8LUsfPFs=
PFcbjs5J37G8ButQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dEjuLEaQa=
B%3DA6ughoxdbB8LUsfPFsPFcbjs5J37G8ButQ%40mail.gmail.com</a>.<br />

--001a1137156659a66a052d8ec240--

.

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

Following precedence *is* left-to-right.  Given a() + b() * c(), or a() *
b() + c(), or a() * (b() + c()), or similar constructs, is there any case
where the functions wouldn't be called in the order a(), b(), c()?

Similarly, associativity tells you that a() =3D b() =3D c() means a() =3D (=
b() =3D
c()), but I don't see why that leads to the conclusion that an order other
than a(), b(), c() is better for this computation.

On Tue, Mar 8, 2016 at 2:40 PM, Farid Mehrabi <farid.mehrabi@gmail.com>
wrote:

> =E2=80=8BI know i am rushing. But....
> =E2=80=8BWhy should the evaluation order not follow that of precedence an=
d
> associativity(considering ltr for the case of function call)?
> lately I posted a well-known ancient example of UB regarding evaluation
> sequence in a forum:
>
> cout << x  <<"," << ++x << endl;
>
> the first reply came from a novice claiming that he could see no UB!!!!
> I mean when the AST is present, what reason should prevent the compiler
> from following it in evaluating parameters?
>
> regards,
> FM.
>
> 2016-03-08 21:19 GMT+03:30 'Edward Catmur' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org>:
>
>> On Tue, Mar 8, 2016 at 3:43 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
>>>
>>> What do you mean by that? That there's nothing wrong with young student=
s
>>> being frustrated by C++ and not explore it further and instead join the
>>> crowd of ignorant developers who get a panic attack when hearing the wo=
rd
>>> "pointer"? I want as many computer science students as possible to like=
 and
>>> use C++ because that includes the understanding of the underlying machi=
ne
>>> interfaction engineering principles they may never learn in any of thos=
e
>>> fancy higher-level languages.
>>>
>>
>> Pretending that the underlying machine executes instructions in serial
>> actively impedes computer science students' understanding, ignoring deca=
des
>> of advances in processor technology: microcode, deep pipelines,
>> hyperthreading, speculative execution, dynamic execution etc. Simplifyin=
g
>> the machine model to make it easier to explain to students is not only
>> patronizing, it does those students a huge disservice.
>>
>> On Tue, Mar 8, 2016 at 4:32 PM, Hyman Rosen <hyman.rosen@gmail.com>
>>  wrote:
>>
>>> A computer program is the means whereby a computer is instructed to
>>> carry out a computation.  Allowing the meaning of parts of a program to=
 be
>>> unspecified is a failure to provide specific instructions to the comput=
er,
>>> and to the extent that the author of the program did not mean this lack=
 of
>>> specificity, is a trap for the author and for all future users of the
>>> program.
>>>
>>
>> The meaning is fully specified. The behavior may not be, but that is
>> irrelevant; a program that fully specifies behavior would be so inflexib=
le
>> as to be useless.
>>
>> --
>> 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/CAJnLdObuyF=
80GRWX6ZABswiXo2Wqzky2stODuh_OUHWgie0TZQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObuy=
F80GRWX6ZABswiXo2Wqzky2stODuh_OUHWgie0TZQ%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter>
>> .
>>
>
>
>
> --
> how am I supposed to end the twisted road of  your hair in such a dark
> night??
> unless the candle of your face does shed some light upon my 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/CALDL7dEjuLE=
aQaB%3DA6ughoxdbB8LUsfPFsPFcbjs5J37G8ButQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dEjuL=
EaQaB%3DA6ughoxdbB8LUsfPFsPFcbjs5J37G8ButQ%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/CAHSYqdbShX%3DwE8snBjapf%3DkFHtc6RpVdwV63F7tNqBV=
K53t_3w%40mail.gmail.com.

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

<div dir=3D"ltr">Following precedence *is* left-to-right.=C2=A0 Given a() +=
 b() * c(), or a() * b() + c(), or a() * (b() + c()), or similar constructs=
, is there any case where the functions wouldn&#39;t be called in the order=
 a(), b(), c()?<br><br>Similarly, associativity tells you that a() =3D b() =
=3D c() means a() =3D (b() =3D c()), but I don&#39;t see why that leads to =
the conclusion that an order other than a(), b(), c() is better for this co=
mputation.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Tue, Mar 8, 2016 at 2:40 PM, Farid Mehrabi <span dir=3D"ltr">&lt;<a href=
=3D"mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.c=
om</a>&gt;</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"rtl"=
><div dir=3D"ltr" class=3D"gmail_default" style=3D"font-family:&#39;arial n=
arrow&#39;,sans-serif;font-size:large">=E2=80=8BI know i am rushing. But...=
..</div><div dir=3D"ltr" class=3D"gmail_default" style=3D"font-family:&#39;a=
rial narrow&#39;,sans-serif;font-size:large">=E2=80=8BWhy should the evalua=
tion order not follow that of precedence and associativity(considering ltr =
for the=C2=A0case of=C2=A0function call)?</div><div dir=3D"ltr" class=3D"gm=
ail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-si=
ze:large">lately I posted a well-known ancient example of UB regarding eval=
uation sequence in a forum:</div><div dir=3D"ltr" class=3D"gmail_default" s=
tyle=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br>=
</div><div dir=3D"ltr" class=3D"gmail_default" style=3D"font-family:&#39;ar=
ial narrow&#39;,sans-serif;font-size:large">cout &lt;&lt; x =C2=A0&lt;&lt;&=
quot;,&quot; &lt;&lt; ++x &lt;&lt; endl;</div><div dir=3D"ltr" class=3D"gma=
il_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-siz=
e:large"><br></div><div dir=3D"ltr" class=3D"gmail_default" style=3D"font-f=
amily:&#39;arial narrow&#39;,sans-serif;font-size:large">the first reply ca=
me from a novice claiming that he could see no UB!!!!</div><div dir=3D"ltr"=
 class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-s=
erif;font-size:large">I mean when the AST is present, what reason should pr=
event the compiler from following it in evaluating parameters?</div><div di=
r=3D"ltr" class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#3=
9;,sans-serif;font-size:large"><br></div><div dir=3D"ltr" class=3D"gmail_de=
fault" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:lar=
ge">regards,</div><div dir=3D"ltr" class=3D"gmail_default" style=3D"font-fa=
mily:&#39;arial narrow&#39;,sans-serif;font-size:large">FM.</div></div><div=
 class=3D"gmail_extra"><div><div class=3D"h5"><br><div class=3D"gmail_quote=
"><div dir=3D"ltr">2016-03-08 21:19 GMT+03:30 &#39;Edward Catmur&#39; via I=
SO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:=
std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt=
;</span>:</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"><span>On Tue, Mar 8, 2016 at 3:=
43 PM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"mailto:miro.knejp@gmail.=
com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</span> wrote:<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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    What do you mean by that? That there&#39;s nothing wrong with young
    students being frustrated by C++ and not explore it further and
    instead join the crowd of ignorant developers who get a panic attack
    when hearing the word &quot;pointer&quot;? I want as many computer scie=
nce
    students as possible to like and use C++ because that includes the
    understanding of the underlying machine interfaction engineering
    principles they may never learn in any of those fancy higher-level
    languages.<br></div></blockquote><div><br></div></span><div>Pretending =
that the underlying machine executes instructions in serial actively impede=
s computer science students&#39; understanding, ignoring decades of advance=
s in processor technology: microcode, deep pipelines, hyperthreading, specu=
lative execution, dynamic execution etc. Simplifying the machine model to m=
ake it easier to explain to students is not only patronizing, it does those=
 students a huge disservice.</div><span><div><br></div><div>On Tue, Mar 8, =
2016 at 4:32 PM, Hyman Rosen=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:h=
yman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt;</span=
>=C2=A0wrote:<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-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr">A computer program is th=
e means whereby a computer is instructed to carry out a computation.=C2=A0 =
Allowing the meaning of parts of a program to be unspecified is a failure t=
o provide specific instructions to the computer, and to the extent that the=
 author of the program did not mean this lack of specificity, is a trap for=
 the author and for all future users of the program.</div></blockquote></di=
v><div><br></div></span><div>The meaning is fully specified. The behavior m=
ay not be, but that is irrelevant; a program that fully specifies behavior =
would be so inflexible as to be useless.=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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAJnLdObuyF80GRWX6ZABswiXo2Wqzky2stOD=
uh_OUHWgie0TZQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAJnLdObuyF80GRWX6ZABswiXo2Wqzky2stODuh_OUHWgie0TZQ%40mail.gmail.com</=
a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div></div></div>-- <br>=
<div><div dir=3D"rtl"><div><div dir=3D"ltr">how am I supposed to end the tw=
isted road of=C2=A0 your hair in such a dark night??<br>unless the candle o=
f your face does shed some light upon my way!!!<br></div></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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CALDL7dEjuLEaQaB%3DA6ughoxdbB8LUsfPFs=
PFcbjs5J37G8ButQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALDL7dEjuLEaQaB%3DA6ughoxdbB8LUsfPFsPFcbjs5J37G8ButQ%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbShX%3DwE8snBjapf%3DkFHtc6RpVd=
wV63F7tNqBVK53t_3w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbShX%3=
DwE8snBjapf%3DkFHtc6RpVdwV63F7tNqBVK53t_3w%40mail.gmail.com</a>.<br />

--001a11438a4efcfa4d052d907acb--

.

--047d7bdca4402a3fe5052d90969f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 8, 2016 at 7:40 PM, Farid Mehrabi <farid.mehrabi@gmail.com>
wrote:

> =E2=80=8BWhy should the evaluation order not follow that of precedence an=
d
> associativity(considering ltr for the case of function call)?
>
> I mean when the AST is present, what reason should prevent the compiler
> from following it in evaluating parameters?
>

A couple of possibilities: CSE, register pressure, instruction timing.
Pretty much any non-peephole optimization can benefit from free ordering of
evaluating subexpressions.

--=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/CAJnLdObvUVt6o%2BiNjTM0pXhrJY6fxXD9L%2BaP6sQ1Qth=
uAyZ24A%40mail.gmail.com.

--047d7bdca4402a3fe5052d90969f
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"><fon=
t face=3D"arial, helvetica, sans-serif">On Tue, Mar 8, 2016 at 7:40 PM, Far=
id Mehrabi <span dir=3D"ltr">&lt;<a href=3D"mailto:farid.mehrabi@gmail.com"=
 target=3D"_blank">farid.mehrabi@gmail.com</a>&gt;</span> wrote:<br></font>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"rtl"><div><span style=3D"font-fa=
mily:arial,helvetica,sans-serif">=E2=80=8BWhy should the evaluation order n=
ot follow that of precedence and associativity(considering ltr for the=C2=
=A0case of=C2=A0function call)?</span><br></div><div><br></div><div><font f=
ace=3D"arial, helvetica, sans-serif">I mean when the AST is present, what r=
eason should prevent the compiler from following it in evaluating parameter=
s?</font></div></div></blockquote><div><br></div><div>A couple of possibili=
ties: CSE, register pressure, instruction timing. Pretty much any non-peeph=
ole optimization can benefit from free ordering of evaluating subexpression=
s.</div><div><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObvUVt6o%2BiNjTM0pXhrJY6fxXD9L%=
2BaP6sQ1QthuAyZ24A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObvUVt6=
o%2BiNjTM0pXhrJY6fxXD9L%2BaP6sQ1QthuAyZ24A%40mail.gmail.com</a>.<br />

--047d7bdca4402a3fe5052d90969f--

.

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

>
> A couple of possibilities: CSE, register pressure, instruction timing.
> Pretty much any non-peephole optimization can benefit from free ordering =
of
> evaluating subexpressions.


Under the as-if rule, the compiler is free to optimize as it wants. Just
because we specify an evaluation order doesn't mean the machine
instructions have to be emitted in a particular order. If the compiler
can't optimize effectively because the side-effects of the subexpressions
are unknown, then it seems unlikely that significant optimization was going
to happen anyways. If the compiler can't optimize as effectively because
there are multiple side-effects which it was previously reordering
optimally but can no longer reorder optimally, then that seems like a
potentially legitimate (if rare) scenario for concern. However, in that
scenario, the semantics of the code were probably undefined anyways since
OOE was undefined.

I think we should focus on getting the right semantics.

We have some code which uses a style like this for declaring UI elements:

new Window().add(
   new BorderElement(3_px).add(
      new Scroller().add( new TextBox("Hello"), new Image("chat.png")  ),
      new Hyperlink("help.html")
    ) );


Though the syntax is handy, you can imagine that expressions like this are
really dangerous for any side-effects they might have. Code like this
definitely wants an evaluation order.

There's a fair argument that this code shouldn't be written like this in
C++ today, but there's also a fair argument that this is a useful way of
writing some things and maybe we should think about making code like this
less dangerous. At least in our case, this is also code where performance
is of effectively 0 concern since it is dead cold.

On Tue, Mar 8, 2016 at 3:51 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Tue, Mar 8, 2016 at 7:40 PM, Farid Mehrabi <farid.mehrabi@gmail.com>
> wrote:
>
>> =E2=80=8BWhy should the evaluation order not follow that of precedence a=
nd
>> associativity(considering ltr for the case of function call)?
>>
>> I mean when the AST is present, what reason should prevent the compiler
>> from following it in evaluating parameters?
>>
>
> A couple of possibilities: CSE, register pressure, instruction timing.
> Pretty much any non-peephole optimization can benefit from free ordering =
of
> evaluating subexpressions.
>
> --
> You received this message because you are 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/CAJnLdObvUVt=
6o%2BiNjTM0pXhrJY6fxXD9L%2BaP6sQ1QthuAyZ24A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObvUV=
t6o%2BiNjTM0pXhrJY6fxXD9L%2BaP6sQ1QthuAyZ24A%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/CADbh%2BeTxLdHsCjT7YadsYWyjixPzSZL6zAeH%2Bq2JwA-=
8%3DR%2B%3DgQ%40mail.gmail.com.

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

<div dir=3D"ltr"><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);bor=
der-left-style:solid;padding-left:1ex"><span style=3D"font-size:12.8px">A c=
ouple of possibilities: CSE, register pressure, instruction timing. Pretty =
much any non-peephole optimization can benefit from free ordering of evalua=
ting subexpressions.</span></blockquote><br></div><div>Under the as-if rule=
, the compiler is free to optimize as it wants. Just because we specify an =
evaluation order doesn&#39;t mean the machine instructions have to be emitt=
ed in a particular order. If the compiler can&#39;t optimize effectively be=
cause the side-effects of the subexpressions are unknown, then it seems unl=
ikely that significant optimization was going to happen anyways. If the com=
piler can&#39;t optimize as effectively because there are multiple side-eff=
ects which it was previously reordering optimally but can no longer reorder=
 optimally, then that seems like a potentially legitimate (if rare) scenari=
o for concern. However, in that scenario, the semantics of the code were pr=
obably undefined anyways since OOE was undefined.</div><div><br></div><div>=
I think we should focus on getting the right semantics.</div><div><br></div=
><div><div>We have some code which uses a style like this for declaring UI =
elements:</div><div><br></div></div><blockquote style=3D"margin:0 0 0 40px;=
border:none;padding:0px"><div><div>new Window().add(=C2=A0</div></div><div>=
<div>=C2=A0 =C2=A0new BorderElement(3_px).add(</div></div><div><div>=C2=A0 =
=C2=A0 =C2=A0 new Scroller().add( new TextBox(&quot;Hello&quot;), new Image=
(&quot;chat.png&quot;) =C2=A0),</div></div><div><div>=C2=A0 =C2=A0 =C2=A0 n=
ew Hyperlink(&quot;help.html&quot;)</div></div><div><div>=C2=A0 =C2=A0 ) );=
</div></div></blockquote><div><div><br></div><div>Though the syntax is hand=
y, you can imagine that expressions like this are really dangerous for any =
side-effects they might have. Code like this definitely wants an evaluation=
 order.</div></div><div><br></div><div>There&#39;s a fair argument that thi=
s code shouldn&#39;t be written like this in C++ today, but there&#39;s als=
o a fair argument that this is a useful way of writing some things and mayb=
e we should think about making code like this less dangerous. At least in o=
ur case, this is also code where performance is of effectively 0 concern si=
nce it is dead cold.</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Tue, Mar 8, 2016 at 3:51 PM, &#39;Edward Catmur&#39; vi=
a ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mail=
to:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</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"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><font fac=
e=3D"arial, helvetica, sans-serif">On Tue, Mar 8, 2016 at 7:40 PM, Farid Me=
hrabi <span dir=3D"ltr">&lt;<a href=3D"mailto:farid.mehrabi@gmail.com" targ=
et=3D"_blank">farid.mehrabi@gmail.com</a>&gt;</span> wrote:<br></font></spa=
n><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"rtl"><span class=3D""><div><sp=
an style=3D"font-family:arial,helvetica,sans-serif">=E2=80=8BWhy should the=
 evaluation order not follow that of precedence and associativity(consideri=
ng ltr for the=C2=A0case of=C2=A0function call)?</span><br></div><div><br><=
/div></span><span class=3D""><div><font face=3D"arial, helvetica, sans-seri=
f">I mean when the AST is present, what reason should prevent the compiler =
from following it in evaluating parameters?</font></div></span></div></bloc=
kquote><div><br></div><div>A couple of possibilities: CSE, register pressur=
e, instruction timing. Pretty much any non-peephole optimization can benefi=
t from free ordering of evaluating subexpressions.</div><div><br></div></di=
v></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAJnLdObvUVt6o%2BiNjTM0pXhrJY6fxXD9L%=
2BaP6sQ1QthuAyZ24A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAJnLdObvUVt6o%2BiNjTM0pXhrJY6fxXD9L%2BaP6sQ1QthuAyZ24A%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTxLdHsCjT7YadsYWyjixPzSZL6zA=
eH%2Bq2JwA-8%3DR%2B%3DgQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2=
BeTxLdHsCjT7YadsYWyjixPzSZL6zAeH%2Bq2JwA-8%3DR%2B%3DgQ%40mail.gmail.com</a>=
..<br />

--001a1146defe4151d0052d91a151--

.

--047d7b3a9b3ae88547052d982e33
Content-Type: text/plain; charset=UTF-8

On 8 Mar 2016 23:06, "Brent Friedman" <fourthgeek@gmail.com> wrote:
>>
>> A couple of possibilities: CSE, register pressure, instruction timing.
Pretty much any non-peephole optimization can benefit from free ordering of
evaluating subexpressions.
>
>
> Under the as-if rule, the compiler is free to optimize as it wants. Just
because we specify an evaluation order doesn't mean the machine
instructions have to be emitted in a particular order.

Can we please take it as read that we are discussing optimizations that are
not available under the as if rule?

> If the compiler can't optimize effectively because the side-effects of
the subexpressions are unknown, then it seems unlikely that significant
optimization was going to happen anyways.

What is the justification for this assertion? CSE, for example, can be
applied even when its result is passed to an opaque function.

> If the compiler can't optimize as effectively because there are multiple
side-effects which it was previously reordering optimally but can no longer
reorder optimally, then that seems like a potentially legitimate (if rare)
scenario for concern. However, in that scenario, the semantics of the code
were probably undefined anyways since OOE was undefined.

Unspecified, not undefined. There is a huge difference.

Besides, the issue is not whether the behavior is unspecified, it is
whether it cannot be proven not to be unspecified. We have already covered
opaque functions that the type system does not allow us to assert do not
modify memory accessed elsewhere in the expression; similarly, one can have
pointers that cannot be proved not to alias:

int g(int* p) { return *p = 0; }
int h(int* q) { return *q; }
int f(int* p, int* q) { return g(p) + h(q); }

With free ordering the write to *p and read from *q can execute in
parallel; under strict ordering the compiler must order the read after the
write, or must test p against q.

> I think we should focus on getting the right semantics.
>
> We have some code which uses a style like this for declaring UI elements:
>
>> new Window().add(
>>    new BorderElement(3_px).add(
>>       new Scroller().add( new TextBox("Hello"), new Image("chat.png")  ),
>>       new Hyperlink("help.html")
>>     ) );
>
>
> Though the syntax is handy, you can imagine that expressions like this
are really dangerous for any side-effects they might have. Code like this
definitely wants an evaluation order.

I don't see anything there that would care what order the subexpressions
are evaluated in. Am I missing something?

> There's a fair argument that this code shouldn't be written like this in
C++ today, but there's also a fair argument that this is a useful way of
writing some things and maybe we should think about making code like this
less dangerous. At least in our case, this is also code where performance
is of effectively 0 concern since it is dead cold.

That looks to me like an initialization, so it should be possible to write
using list-initialization syntax. It might be too late for that particular
API, but a wrapper API or next version should be able to manage 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/CAJnLdObzpNT2%2BVVEKU%2BwzaMms_2Jz3uHezuFEA-G3ZuqCCGrvQ%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 8 Mar 2016 23:06, &quot;Brent Friedman&quot; &lt;<a href=3D"mailto:fourt=
hgeek@gmail.com">fourthgeek@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; A couple of possibilities: CSE, register pressure, instruction tim=
ing. Pretty much any non-peephole optimization can benefit from free orderi=
ng of evaluating subexpressions.<br>
&gt;<br>
&gt;<br>
&gt; Under the as-if rule, the compiler is free to optimize as it wants. Ju=
st because we specify an evaluation order doesn&#39;t mean the machine inst=
ructions have to be emitted in a particular order.</p>
<p dir=3D"ltr">Can we please take it as read that we are discussing optimiz=
ations that are not available under the as if rule? </p>
<p dir=3D"ltr">&gt; If the compiler can&#39;t optimize effectively because =
the side-effects of the subexpressions are unknown, then it seems unlikely =
that significant optimization was going to happen anyways.</p>
<p dir=3D"ltr">What is the justification for this assertion? CSE, for examp=
le, can be applied even when its result is passed to an opaque function.</p=
>
<p dir=3D"ltr">&gt; If the compiler can&#39;t optimize as effectively becau=
se there are multiple side-effects which it was previously reordering optim=
ally but can no longer reorder optimally, then that seems like a potentiall=
y legitimate (if rare) scenario for concern. However, in that scenario, the=
 semantics of the code were probably undefined anyways since OOE was undefi=
ned.</p>
<p dir=3D"ltr">Unspecified, not undefined. There is a huge difference. </p>
<p dir=3D"ltr">Besides, the issue is not whether the behavior is unspecifie=
d, it is whether it cannot be proven not to be unspecified. We have already=
 covered opaque functions that the type system does not allow us to assert =
do not modify memory accessed elsewhere in the expression; similarly, one c=
an have pointers that cannot be proved not to alias:</p>
<p dir=3D"ltr">int g(int* p) { return *p =3D 0; }<br>
int h(int* q) { return *q; }<br>
int f(int* p, int* q) { return g(p) + h(q); }</p>
<p dir=3D"ltr">With free ordering the write to *p and read from *q can exec=
ute in parallel; under strict ordering the compiler must order the read aft=
er the write, or must test p against q.</p>
<p dir=3D"ltr">&gt; I think we should focus on getting the right semantics.=
<br>
&gt;<br>
&gt; We have some code which uses a style like this for declaring UI elemen=
ts:<br>
&gt;<br>
&gt;&gt; new Window().add(=C2=A0<br>
&gt;&gt; =C2=A0 =C2=A0new BorderElement(3_px).add(<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0 new Scroller().add( new TextBox(&quot;Hello&q=
uot;), new Image(&quot;chat.png&quot;) =C2=A0),<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0 new Hyperlink(&quot;help.html&quot;)<br>
&gt;&gt; =C2=A0 =C2=A0 ) );<br>
&gt;<br>
&gt;<br>
&gt; Though the syntax is handy, you can imagine that expressions like this=
 are really dangerous for any side-effects they might have. Code like this =
definitely wants an evaluation order.</p>
<p dir=3D"ltr">I don&#39;t see anything there that would care what order th=
e subexpressions are evaluated in. Am I missing something? </p>
<p dir=3D"ltr">&gt; There&#39;s a fair argument that this code shouldn&#39;=
t be written like this in C++ today, but there&#39;s also a fair argument t=
hat this is a useful way of writing some things and maybe we should think a=
bout making code like this less dangerous. At least in our case, this is al=
so code where performance is of effectively 0 concern since it is dead cold=
..</p>
<p dir=3D"ltr">That looks to me like an initialization, so it should be pos=
sible to write using list-initialization syntax. It might be too late for t=
hat particular API, but a wrapper API or next version should be able to man=
age it. </p>

<p></p>

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

--047d7b3a9b3ae88547052d982e33--

.

This is a multi-part message in MIME format.
--------------010500060601080606050105
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 09.03.2016 um 07:55 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>
> On 8 Mar 2016 23:06, "Brent Friedman" <fourthgeek@gmail.com
> <mailto:fourthgeek@gmail.com>> wrote:
> >>
> >> A couple of possibilities: CSE, register pressure, instruction
> timing. Pretty much any non-peephole optimization can benefit from
> free ordering of evaluating subexpressions.
> >
> >
> > Under the as-if rule, the compiler is free to optimize as it wants.
> Just because we specify an evaluation order doesn't mean the machine
> instructions have to be emitted in a particular order.
>
> Can we please take it as read that we are discussing optimizations
> that are not available under the as if rule?
>
> > If the compiler can't optimize effectively because the side-effects
> of the subexpressions are unknown, then it seems unlikely that
> significant optimization was going to happen anyways.
>
> What is the justification for this assertion? CSE, for example, can be
> applied even when its result is passed to an opaque function.
>
> > If the compiler can't optimize as effectively because there are
> multiple side-effects which it was previously reordering optimally but
> can no longer reorder optimally, then that seems like a potentially
> legitimate (if rare) scenario for concern. However, in that scenario,
> the semantics of the code were probably undefined anyways since OOE
> was undefined.
>
> Unspecified, not undefined. There is a huge difference.
>
And that is? I may not be a native English speaker but every page on the
internet tells me unspecified and undefined are synonyms. As they are in
German and Czech so I'm really curious now. Would you please elaborate
what the difference is?

--
You received this message because you are 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/56DFE070.4050200%40gmail.com.

--------------010500060601080606050105
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 09.03.2016 um 07:55 schrieb 'Edward Catmur' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CAJnLdObzpNT2+VVEKU+wzaMms_2Jz3uHezuFEA-G3ZuqCCGrvQ@mail.gmail.=
com"
      type=3D"cite">
      <p dir=3D"ltr"><br>
        On 8 Mar 2016 23:06, "Brent Friedman" &lt;<a
          moz-do-not-send=3D"true" href=3D"mailto:fourthgeek@gmail.com"><a =
class=3D"moz-txt-link-abbreviated" href=3D"mailto:fourthgeek@gmail.com">fou=
rthgeek@gmail.com</a></a>&gt;
        wrote:<br>
        &gt;&gt;<br>
        &gt;&gt; A couple of possibilities: CSE, register pressure,
        instruction timing. Pretty much any non-peephole optimization
        can benefit from free ordering of evaluating subexpressions.<br>
        &gt;<br>
        &gt;<br>
        &gt; Under the as-if rule, the compiler is free to optimize as
        it wants. Just because we specify an evaluation order doesn't
        mean the machine instructions have to be emitted in a particular
        order.</p>
      <p dir=3D"ltr">Can we please take it as read that we are discussing
        optimizations that are not available under the as if rule? </p>
      <p dir=3D"ltr">&gt; If the compiler can't optimize effectively
        because the side-effects of the subexpressions are unknown, then
        it seems unlikely that significant optimization was going to
        happen anyways.</p>
      <p dir=3D"ltr">What is the justification for this assertion? CSE,
        for example, can be applied even when its result is passed to an
        opaque function.</p>
      <p dir=3D"ltr">&gt; If the compiler can't optimize as effectively
        because there are multiple side-effects which it was previously
        reordering optimally but can no longer reorder optimally, then
        that seems like a potentially legitimate (if rare) scenario for
        concern. However, in that scenario, the semantics of the code
        were probably undefined anyways since OOE was undefined.</p>
      <p dir=3D"ltr">Unspecified, not undefined. There is a huge
        difference. </p>
    </blockquote>
    And that is? I may not be a native English speaker but every page on
    the internet tells me unspecified and undefined are synonyms. As
    they are in German and Czech so I'm really curious now. Would you
    please elaborate what the difference is?<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/56DFE070.4050200%40gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/ms=
gid/std-proposals/56DFE070.4050200%40gmail.com</a>.<br />

--------------010500060601080606050105--

.

This is a multi-part message in MIME format.
--------------070303090606010702000605
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable



On 09/03/2016 09:36, Miro Knejp wrote:
> Am 09.03.2016 um 07:55 schrieb 'Edward Catmur' via ISO C++ Standard -=20
> Future Proposals:
>> > If the compiler can't optimize as effectively because there are=20
>> multiple side-effects which it was previously reordering optimally=20
>> but can no longer reorder optimally, then that seems like a=20
>> potentially legitimate (if rare) scenario for concern. However, in=20
>> that scenario, the semantics of the code were probably undefined=20
>> anyways since OOE was undefined.
>>
>> Unspecified, not undefined. There is a huge difference.
>>
> And that is? I may not be a native English speaker but every page on=20
> the internet tells me unspecified and undefined are synonyms. As they=20
> are in German and Czech so I'm really curious now. Would you please=20
> elaborate what the difference is?
>

Both are terms of art, i.e. while they might be synonyms in normal=20
English they get assigned different meanings by the standard:
- undefined behavior - means that the standard does not define any=20
behavior to the program at all, i.e. the program is broken and the=20
compiler is at liberty to emit any code it wants. [1]-=C2=A71.3.25
- unspecified behavior - means that out of several viable options the=20
standard does not specify which to take, the compiler is at liberty to=20
select any of the viable options, and is allowed to select a different=20
one at each run. [1]-=C2=A71.3.26
- implementation defined behavior - means nearly the same thing as=20
above, but the compiler has to select one meaning, document that and=20
stick to it in all compilations [1]-=C2=A71.3.11

best
Fabio

[1] latest draft standard:=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4567.pdf

--=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/56DFE8FA.2060906%40gmx.net.

--------------070303090606010702000605
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">
    <br>
    <br>
    <div class=3D"moz-cite-prefix">On 09/03/2016 09:36, Miro Knejp wrote:<b=
r>
    </div>
    <blockquote cite=3D"mid:56DFE070.4050200@gmail.com" type=3D"cite">
      <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
      Am 09.03.2016 um 07:55 schrieb 'Edward Catmur' via ISO C++
      Standard - Future Proposals:<br>
      <blockquote
cite=3D"mid:CAJnLdObzpNT2+VVEKU+wzaMms_2Jz3uHezuFEA-G3ZuqCCGrvQ@mail.gmail.=
com"
        type=3D"cite">&gt; If the compiler can't optimize as effectively
        because there are multiple side-effects which it was previously
        reordering optimally but can no longer reorder optimally, then
        that seems like a potentially legitimate (if rare) scenario for
        concern. However, in that scenario, the semantics of the code
        were probably undefined anyways since OOE was undefined.
        <p dir=3D"ltr">Unspecified, not undefined. There is a huge
          difference. </p>
      </blockquote>
      And that is? I may not be a native English speaker but every page
      on the internet tells me unspecified and undefined are synonyms.
      As they are in German and Czech so I'm really curious now. Would
      you please elaborate what the difference is?<br>
      <br>
    </blockquote>
    <br>
    Both are terms of art, i.e. while they might be synonyms in normal
    English they get assigned different meanings by the standard: <br>
    - undefined behavior - means that the standard does not define any
    behavior to the program at all, i.e. the program is broken and the
    compiler is at liberty to emit any code it wants. [1]-=C2=A71.3.25<br>
    - unspecified behavior - means that out of several viable options
    the standard does not specify which to take, the compiler is at
    liberty to select any of the viable options, and is allowed to
    select a different one at each run. [1]-=C2=A71.3.26<br>
    - implementation defined behavior - means nearly the same thing as
    above, but the compiler has to select one meaning, document that and
    stick to it in all compilations [1]-=C2=A71.3.11<br>
    <br>
    best<br>
    Fabio<br>
    <br>
    [1] latest draft standard:
    <a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2015/n4567.pdf">http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2015/n4567.pdf</a><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/56DFE8FA.2060906%40gmx.net?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/56DFE8FA.2060906%40gmx.net</a>.<br />

--------------070303090606010702000605--

.

------=_Part_203_1743093855.1457522948845
Content-Type: multipart/alternative;
 boundary="----=_Part_204_1669328630.1457522948845"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8B=E5=8D=8811:41:26=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 08.03.2016 um 15:32 schrieb FrankHB1989:
>
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UT=
C+8=E4=B8=8A=E5=8D=883:56:12=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A=
=20
>
> Am 04.03.2016 um 13:04 schrieb 'Edward Catmur' via ISO C++ Standard -=20
> Future Proposals:
>
>
> On 4 Mar 2016 12:29, "Miro Knejp" <miro....@gmail.com> wrote:
> >
> > People have wildly different expectations, and that largely depends on=
=20
> what they start programming with. And people who have never programmed=20
> before usually have expectations that have no connection to the technical=
=20
> reality. Those who grow up speaking and writing a left-to-right language=
=20
> have it ingrained in their head that all sequences of things are=20
> let-to-right as that is the direction they read and write in. In math cla=
ss=20
> they are given the exercise f(g(x) + h(x)) and how do they intuitively=20
> solve it? They calculate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, the=
n f(c).=20
> Try getting rid of this intuition after applying it for several years=20
> during the phase of your live where the brain solidifies such patterns.=
=20
> They expect the programming language to work the same because programming=
=20
> and math are very closely related, and all the modern languages actually=
=20
> *do* fulfill this expectation.
> >
>
> What do they do when given f(x) + g(x) * h(x)?
>
> Mathematical formulae - which programming language expressions model - do=
=20
> not have side effects, so intermediate results can be computed in any=20
> order.=20
>
> That's not the point. It doesn't matter whether math formulas have no sid=
e=20
> effects or that they can be evaluated in any order. What matters is the=
=20
> underlying psychology of the people who do the exercise, and later the=20
> programming course. If they're used to a certain way of solving these=20
> problems and have trained that during a critical phase of brain develomen=
t,=20
> they apply it to everything. It's a pattern, and our brain is very good a=
t=20
> identifying and applying patterns, but horrifically bad at abandoning=20
> existing patterns.
>
>
> The syntactic design of many ALGOL-derived languages are clearly effected=
=20
> by the math notation. Learners of such languages are often required have=
=20
> background knowledge about such syntax style. So the underlying psycholog=
y=20
> of most people should be similar at first. When there are semantics stuff=
,=20
> things get complicated, because there is nothing "side effects" in=20
> traditional math they have learned. Syntax of math can be considered bad=
=20
> pattern, but the fresh rules of semantics should be not.
>
> Back then only few people did study computer science, and those were=20
> usually like-minded people (i.e. nerds) who came into university with ton=
s=20
> of similar prior knowledge. Today we have millions of students leaving=20
> school at 18 and entering computer science studies since it became=20
> mainstream. Today these students have vastly different backgrounds in=20
> education and interests and it's dangerous to assume otherwise.

Haven't they known what f(x, y) is from the middle school math course?
=20

> Many of them had no prior exposure to programming at all, but that doesn'=
t=20
> automatically mean they cannot become great programmers. We shouldn't=20
> "require" any further background knowledge from students than what they g=
et=20
> from the school or university curriculums. The easier we can make it for=
=20
> people to understand the language and the underlying concepts, apply it o=
n=20
> their own, and keep them motivated and intersted the better for the=20
> industry.


Teachability is not the excuse of laziness. Many of them now know they have=
=20
understood, but they are actually not. That's cheating.

The required background knowledge at school is usually simpler than=20
domain-specific requirements of the industry.

Since it is already "mainstream", I am not afraid to kill the interest of=
=20
most of them. There have been already a lot of half-baked noobs which need=
=20
too much extra manpower to cleanup in the industry.
=20

> There aren't going to be less programming jobs in the future, so much is=
=20
> pretty much certain. And I'd prefer these graduates to not be scared of C=
++=20
> but to proudly say it is one of their favorites. These people also need t=
o=20
> have a proper understanding of the software+hardware interaction (somethi=
ng=20
> I see missing a lot today), which they won't get if they are only exposed=
=20
> to C# or Java because they abandoned C++ due to its inconsistencies and=
=20
> frustration points.
>

They will probably not occur. As you mentioned previously, they will more=
=20
easily embrace Java than C++. Even this will be true, they will eventually=
=20
invent another dialect of C++ (likely with patches including the proposed=
=20
rules here), with regardless of the which language specification to=20
conform. Further, they will likely think they master C++ because C++ is=20
just the thing they have expected, even they actually don't know what is=20
C++ and what is not in C++ *by definition*. That's plain absurd. A thousand=
=20
eyes of the audience have 1000 Hamlet, but 1000 kinds of C++ are useless.

> Any reasonably competent student will exploit this to perform CSE and=20
> other rewriting tricks to simplify the computation, so the similar tricks=
=20
> the compiler performs should be intimately familiar.=20
>
> They do CSE because it saves *them* work, because it saves *them* time on=
=20
> exams, but a machine doesn't care about that and most class or home=20
> exercises finish computing quickly enough that execution time doesn't=20
> matter. I argue that most beginner programming students pay optimization=
=20
> absolutely no attention and probably don't even know such a thing exists.=
=20
> Those with prior experience, yes, but the majority don't until they=20
> actually get into courses that deal with data structures, algorithms,=20
> complexities and code transforming optimizations, but until they receive=
=20
> (and understand) that knowledge they may have already decided that C++ is=
 a=20
> stupid language and that Java is all the awesomeness.
>
>
> Nothing wrong.
>
> What do you mean by that? That there's nothing wrong with young students=
=20
> being frustrated by C++ and not explore it further and instead join the=
=20
> crowd of ignorant developers who get a panic attack when hearing the word=
=20
> "pointer"? I want as many computer science students as possible to like a=
nd=20
> use C++ because that includes the understanding of the underlying machine=
=20
> interfaction engineering principles they may never learn in any of those=
=20
> fancy higher-level languages.
>
> There is nothing wrong for someone who can't play with C++ well. It will=
=20
be wrong to force them learning and using C++ if they are already=20
frustrated. Give them choices.

Though C++ is a general-purposed language, it is not always fit for all=20
kinds of tasks. And it is not specifically invented to make people more=20
easily understand machine interaction principles. It only works well for=20
people who have already known what things should be truly low-level and=20
under control in special ways. In this case learners of C++ are required to=
=20
be able to switch their mind between low-level and highly abstract contexts=
=20
rapidly once needed, which may be a pain for people who only want to do=20
low-level works.

The built-in pointer is obviously a stupid design to what it serves to. But=
=20
that's not a big matter unless they want to change the language itself.=20
There exist many workarounds.

For those who feel things above are not so obvious, switching a language=20
other than C++ (including C) will likely please them a lot.
=20

> If young people don't want to learn and use C++ there is either a problem=
=20
> with the language, or the theacher, or both. The more compilcated the rul=
es=20
> get and the more exceptions there are the more difficult we make it for=
=20
> newcomers.
>
> Then, too, when they're learning fundamentals of programming languages,=
=20
> they will discover that the order in which term rewriting rules are appli=
ed=20
> can affect, if not the result, then certainly how long it takes to reach=
=20
> the result and even whether the result is reached at all (for weakly=20
> normalizing terms).
>
> This kind of transformation is only dealt with in courses that actually=
=20
> teach the topic of code transforming optimizations. But often theses=20
> courses are considered advanced, and sometimes even optional. The topic o=
f=20
> "performance" is typically only touched on in courses dealing with data=
=20
> structures and algorithmic complexity, but those exercises don't have=20
> execution times which are saved by subexpression reordering, they are=20
> tailored specifically to show the difference betwen a hash map and a link=
ed=20
> list.
>
>
> Still nothing wrong.=20
>
> So I don't believe that programming novices expect any particular=20
> evaluation order, irrespective of what human languages they speak.=20
>
> Don't underestimate the impact a language can have on how people think.=
=20
> There is evidence pointing in the direction=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/0e4e59ac-8576-4964-9b66-80154addd512%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=888=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8811:41:26=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
    Am 08.03.2016 um 15:32 schrieb FrankHB1989:<br>
    <blockquote>
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=
=AD UTC+8=E4=B8=8A=E5=8D=883:56:12=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=
=BC=9A
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF"> Am 04.03.2016 um 13:04
            schrieb &#39;Edward Catmur&#39; via ISO C++ Standard - Future
            Proposals:<br>
            <blockquote>
              <p dir=3D"ltr"><br>
                On 4 Mar 2016 12:29, &quot;Miro Knejp&quot; &lt;<a rel=3D"n=
ofollow"></a><a>miro....@gmail.com</a>&gt;

                wrote:<br>
                &gt;<br>
                &gt; People have wildly different expectations, and that
                largely depends on what they start programming with. And
                people who have never programmed before usually have
                expectations that have no connection to the technical
                reality. Those who grow up speaking and writing a
                left-to-right language have it ingrained in their head
                that all sequences of things are let-to-right as that is
                the direction they read and write in. In math class they
                are given the exercise f(g(x) + h(x)) and how do they
                intuitively solve it? They calculate a=3Dg(x) first, then
                b=3Dh(x), then c=3Da+b, then f(c). Try getting rid of this
                intuition after applying it for several years during the
                phase of your live where the brain solidifies such
                patterns. They expect the programming language to work
                the same because programming and math are very closely
                related, and all the modern languages actually *do*
                fulfill this expectation.<br>
                &gt;</p>
              <p dir=3D"ltr">What do they do when given f(x) + g(x) *
                h(x)?</p>
              <p dir=3D"ltr">Mathematical formulae - which programming
                language expressions model - do not have side effects,
                so intermediate results can be computed in any order. </p>
            </blockquote>
            That&#39;s not the point. It doesn&#39;t matter whether math
            formulas have no side effects or that they can be evaluated
            in any order. What matters is the underlying psychology of
            the people who do the exercise, and later the programming
            course. If they&#39;re used to a certain way of solving these
            problems and have trained that during a critical phase of
            brain develoment, they apply it to everything. It&#39;s a
            pattern, and our brain is very good at identifying and
            applying patterns, but horrifically bad at abandoning
            existing patterns.<br>
          </div>
        </blockquote>
        <div><br>
          The syntactic design of many ALGOL-derived languages are
          clearly effected by the math notation. Learners of such
          languages are often required have background knowledge about
          such syntax style. So the underlying psychology of most people
          should be similar at first. When there are semantics stuff,
          things get complicated, because there is nothing &quot;side
          effects&quot; in traditional math they have learned. Syntax of ma=
th
          can be considered bad pattern, but the fresh rules of
          semantics should be not.<br>
        </div>
      </div>
    </blockquote>
    Back then only few people did study computer science, and those were
    usually like-minded people (i.e. nerds) who came into university
    with tons of similar prior knowledge. Today we have millions of
    students leaving school at 18 and entering computer science studies
    since it became mainstream. Today these students have vastly
    different backgrounds in education and interests and it&#39;s dangerous
    to assume otherwise.</blockquote><div>Haven&#39;t they known what f(x, =
y) is from the middle school math course?<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Many of them had no prior exposure to
    programming at all, but that doesn&#39;t automatically mean they cannot
    become great programmers. We shouldn&#39;t &quot;require&quot; any furt=
her
    background knowledge from students than what they get from the
    school or university curriculums. The easier we can make it for
    people to understand the language and the underlying concepts, apply
    it on their own, and keep them motivated and intersted the better
    for the industry.</blockquote><div><br>Teachability is not the excuse o=
f laziness. Many of them now know they have understood, but they are actual=
ly not. That&#39;s cheating.<br><br>The required background knowledge at sc=
hool is usually simpler than domain-specific requirements of the industry.<=
br><br>Since it is already &quot;mainstream&quot;, I am not afraid to kill =
the interest of most of them. There have been already a lot of half-baked n=
oobs which need too much extra manpower to cleanup in the industry.<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;">There aren&#39;t goin=
g to be less programming jobs in
    the future, so much is pretty much certain. And I&#39;d prefer these
    graduates to not be scared of C++ but to proudly say it is one of
    their favorites. These people also need to have a proper
    understanding of the software+hardware interaction (something I see
    missing a lot today), which they won&#39;t get if they are only exposed
    to C# or Java because they abandoned C++ due to its inconsistencies
    and frustration points.<br></blockquote><div><br>They will probably not=
 occur. As you mentioned previously, they will more easily embrace Java tha=
n C++. Even this will be true, they will eventually invent another dialect =
of C++ (likely with patches including the proposed rules here), with regard=
less of the which language specification to conform. Further, they will lik=
ely think they master C++ because C++ is just the thing they have expected,=
 even they actually don&#39;t know what is C++ and what is not in C++ <i>by=
 definition</i>. That&#39;s plain absurd. A thousand eyes of the audience h=
ave 1000 Hamlet, but 1000 kinds of C++ are useless.<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
    <blockquote>
      <div dir=3D"ltr">
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF">
            <blockquote>
              <p dir=3D"ltr">Any reasonably competent student will exploit
                this to perform CSE and other rewriting tricks to
                simplify the computation, so the similar tricks the
                compiler performs should be intimately familiar. </p>
            </blockquote>
            They do CSE because it saves *them* work, because it saves
            *them* time on exams, but a machine doesn&#39;t care about that
            and most class or home exercises finish computing quickly
            enough that execution time doesn&#39;t matter. I argue that mos=
t
            beginner programming students pay optimization absolutely no
            attention and probably don&#39;t even know such a thing exists.
            Those with prior experience, yes, but the majority don&#39;t
            until they actually get into courses that deal with data
            structures, algorithms, complexities and code transforming
            optimizations, but until they receive (and understand) that
            knowledge they may have already decided that C++ is a stupid
            language and that Java is all the awesomeness.<br>
          </div>
        </blockquote>
        <div><br>
          Nothing wrong.<br>
        </div>
      </div>
    </blockquote>
    What do you mean by that? That there&#39;s nothing wrong with young
    students being frustrated by C++ and not explore it further and
    instead join the crowd of ignorant developers who get a panic attack
    when hearing the word &quot;pointer&quot;? I want as many computer scie=
nce
    students as possible to like and use C++ because that includes the
    understanding of the underlying machine interfaction engineering
    principles they may never learn in any of those fancy higher-level
    languages.<br>
    <br></blockquote><div>There is nothing wrong for someone who can&#39;t =
play with C++ well. It will be wrong to force them learning and using C++ i=
f they are already frustrated. Give them choices.<br><br>Though C++ is a ge=
neral-purposed language, it is not always fit for all kinds of tasks. And i=
t is not specifically invented to make people more easily understand machin=
e interaction principles. It only works well for people who have already kn=
own what things should be truly low-level and under control in special ways=
.. In this case learners of C++ are required to be able to switch their mind=
 between low-level and highly abstract contexts rapidly once needed, which =
may be a pain for people who only want to do low-level works.<br><br>The bu=
ilt-in pointer is obviously a stupid design to what it serves to. But that&=
#39;s not a big matter unless they want to change the language itself. Ther=
e exist many workarounds.<br><br>For those who feel things above are not so=
 obvious, switching a language other than C++ (including C) will likely ple=
ase them a lot.<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;">
    If young people don&#39;t want to learn and use C++ there is either a
    problem with the language, or the theacher, or both. The more
    compilcated the rules get and the more exceptions there are the more
    difficult we make it for newcomers.<br>
    <blockquote>
      <div dir=3D"ltr">
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF">
            <blockquote>
              <p dir=3D"ltr">Then, too, when they&#39;re learning fundament=
als
                of programming languages, they will discover that the
                order in which term rewriting rules are applied can
                affect, if not the result, then certainly how long it
                takes to reach the result and even whether the result is
                reached at all (for weakly normalizing terms).</p>
            </blockquote>
            This kind of transformation is only dealt with in courses
            that actually teach the topic of code transforming
            optimizations. But often theses courses are considered
            advanced, and sometimes even optional. The topic of
            &quot;performance&quot; is typically only touched on in courses
            dealing with data structures and algorithmic complexity, but
            those exercises don&#39;t have execution times which are saved
            by subexpression reordering, they are tailored specifically
            to show the difference betwen a hash map and a linked list.<br>
          </div>
        </blockquote>
        <div><br>
          Still nothing wrong. <br>
        </div>
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF">
            <blockquote>
              <p dir=3D"ltr"> So I don&#39;t believe that programming novic=
es
                expect any particular evaluation order, irrespective of
                what human languages they speak. </p>
            </blockquote>
            Don&#39;t underestimate the impact a language can have on how
            people think. There is evidence pointing in the direction
       </div></blockquote></div></blockquote>  ...</blockquote></div>

<p></p>

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

------=_Part_204_1669328630.1457522948845--
------=_Part_203_1743093855.1457522948845--

.

------=_Part_5871_1693810230.1457525000386
Content-Type: multipart/alternative;
 boundary="----=_Part_5872_396556930.1457525000386"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8A=E5=8D=883:41:00=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=9A
>
> =E2=80=8BI know i am rushing. But....
> =E2=80=8BWhy should the evaluation order not follow that of precedence an=
d=20
> associativity(considering ltr for the case of function call)?
> lately I posted a well-known ancient example of UB regarding evaluation=
=20
> sequence in a forum:
>
> cout << x  <<"," << ++x << endl;
>
> the first reply came from a novice claiming that he could see no UB!!!!
> I mean when the AST is present, what reason should prevent the compiler=
=20
> from following it in evaluating parameters?
>
> AST? Do you mean the abstract syntax tree? If so, I'm curious why you wan=
t=20
to make it "present" in your brain. Parsing C++ correctly by machines is=20
already (in)famously difficult and AST may often be not so useful for=20
further analysis as it should be...

A compiler can be formed by transformers between different kinds of=20
IR(intermediate representations). AST is just one (very popular) candidate=
=20
of these IRs. (Poor ancient MSVC's cl has even no clear AST ...) Processing=
=20
AST is distinct with processing source code in general since they are in=20
different *phases* by design of most languages, and in different *passes *o=
f=20
typical implementations (compilers). Source code have to meet the semantic=
=20
requirements of the specification of a language, but the rules about=20
handling IRs are generally absent. Some specifications mention special IR=
=20
without the whole rules, because they are defined (and possibly shared) by=
=20
other specifications, e.g. Java vs. bytecode of Java Virtual Machine. Only=
=20
for some one-pass interpreters the order can be naturally the same, but=20
there is still no need to specify the order in the specification in the=20
language, and that concrete order is not always LTR (even just in a parser)=
..

Note that for a language that has source form very close to an AST (which=
=20
means syntactic parsing, by humans or machines, is generally simple), it=20
can still have deliberated unspecified evaluation order in source=20
constructs, like Scheme.


regards,
> FM.
>
> 2016-03-08 21:19 GMT+03:30 'Edward Catmur' via ISO C++ Standard - Future=
=20
> Proposals <std-pr...@isocpp.org <javascript:>>:
>
> On Tue, Mar 8, 2016 at 3:43 PM, Miro Knejp <miro....@gmail.com=20
> <javascript:>> wrote:
>
> What do you mean by that? That there's nothing wrong with young students=
=20
> being frustrated by C++ and not explore it further and instead join the=
=20
> crowd of ignorant developers who get a panic attack when hearing the word=
=20
> "pointer"? I want as many computer science students as possible to like a=
nd=20
> use C++ because that includes the understanding of the underlying machine=
=20
> interfaction engineering principles they may never learn in any of those=
=20
> fancy higher-level languages.
>
>
> Pretending that the underlying machine executes instructions in serial=20
> actively impedes computer science students' understanding, ignoring decad=
es=20
> of advances in processor technology: microcode, deep pipelines,=20
> hyperthreading, speculative execution, dynamic execution etc. Simplifying=
=20
> the machine model to make it easier to explain to students is not only=20
> patronizing, it does those students a huge disservice.
>
> On Tue, Mar 8, 2016 at 4:32 PM, Hyman Rosen <hyman...@gmail.com=20
> <javascript:>> wrote:
>
> A computer program is the means whereby a computer is instructed to carry=
=20
> out a computation.  Allowing the meaning of parts of a program to be=20
> unspecified is a failure to provide specific instructions to the computer=
,=20
> and to the extent that the author of the program did not mean this lack o=
f=20
> specificity, is a trap for the author and for all future users of the=20
> program.
>
>
> The meaning is fully specified. The behavior may not be, but that is=20
> irrelevant; a program that fully specifies behavior would be so inflexibl=
e=20
> as to be useless.=20
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=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/a880752b-8a8d-46bf-ac9b-0652c117170b%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=883:41:00=EF=BC=8CFarid Mehrabi=
=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"rtl"><div dir=3D"ltr" style=3D"font-family:&#39;arial narrow&#39;,=
sans-serif;font-size:large">=E2=80=8BI know i am rushing. But....</div><div=
 dir=3D"ltr" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-si=
ze:large">=E2=80=8BWhy should the evaluation order not follow that of prece=
dence and associativity(considering ltr for the=C2=A0case of=C2=A0function =
call)?</div><div dir=3D"ltr" style=3D"font-family:&#39;arial narrow&#39;,sa=
ns-serif;font-size:large">lately I posted a well-known ancient example of U=
B regarding evaluation sequence in a forum:</div><div dir=3D"ltr" style=3D"=
font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div><d=
iv dir=3D"ltr" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large">cout &lt;&lt; x =C2=A0&lt;&lt;&quot;,&quot; &lt;&lt; ++x &lt;&l=
t; endl;</div><div dir=3D"ltr" style=3D"font-family:&#39;arial narrow&#39;,=
sans-serif;font-size:large"><br></div><div dir=3D"ltr" style=3D"font-family=
:&#39;arial narrow&#39;,sans-serif;font-size:large">the first reply came fr=
om a novice claiming that he could see no UB!!!!</div><div dir=3D"ltr" styl=
e=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">I mean =
when the AST is present, what reason should prevent the compiler from follo=
wing it in evaluating parameters?</div><div dir=3D"ltr" style=3D"font-famil=
y:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div></div></bloc=
kquote><div>AST? Do you mean the abstract syntax tree? If so, I&#39;m curio=
us why you want to make it &quot;present&quot; in your brain. Parsing C++ c=
orrectly by machines is already (in)famously difficult and AST may often be=
 not so useful for further analysis as it should be...<br><br>A compiler ca=
n be formed by transformers between different kinds of IR(intermediate repr=
esentations). AST is just one (very popular) candidate of these IRs. (Poor =
ancient MSVC&#39;s cl has even no clear AST ...) Processing AST is distinct=
 with processing source code in general since they are in different <i>phas=
es</i> by design of most languages, and in different <i>passes </i>of typic=
al implementations (compilers). Source code have to meet the semantic requi=
rements of the specification of a language, but the rules about handling IR=
s are generally absent. Some specifications mention special IR without the =
whole rules, because they are defined (and possibly shared) by other specif=
ications, e.g. Java vs. bytecode of Java Virtual Machine. Only for some one=
-pass interpreters the order can be naturally the same, but there is still =
no need to specify the order in the specification in the language, and that=
 concrete order is not always LTR (even just in a parser).<br><br>Note that=
 for a language that has source form very close to an AST (which means synt=
actic parsing, by humans or machines, is generally simple), it can still ha=
ve deliberated unspecified evaluation order in source constructs, like Sche=
me.<br><br><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"rtl"><div dir=3D"ltr" style=3D"font-family:&#39;arial narrow&#39;,sans-=
serif;font-size:large"></div><div dir=3D"ltr" style=3D"font-family:&#39;ari=
al narrow&#39;,sans-serif;font-size:large">regards,</div><div dir=3D"ltr" s=
tyle=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">FM.<=
/div></div><div><br><div><div dir=3D"ltr">2016-03-08 21:19 GMT+03:30 &#39;E=
dward Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr"=
>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"baz=
C-9RaBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39=
;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">=
std-pr...@isocpp.org</a>&gt;</span>:</div><blockquote style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><d=
iv><span>On Tue, Mar 8, 2016 at 3:43 PM, Miro Knejp <span dir=3D"ltr">&lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"bazC-9RaB=
gAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">miro..=
...@gmail.com</a>&gt;</span> wrote:<blockquote 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 bgcolor=3D"#FFFFFF">
    What do you mean by that? That there&#39;s nothing wrong with young
    students being frustrated by C++ and not explore it further and
    instead join the crowd of ignorant developers who get a panic attack
    when hearing the word &quot;pointer&quot;? I want as many computer scie=
nce
    students as possible to like and use C++ because that includes the
    understanding of the underlying machine interfaction engineering
    principles they may never learn in any of those fancy higher-level
    languages.<br></div></blockquote><div><br></div></span><div>Pretending =
that the underlying machine executes instructions in serial actively impede=
s computer science students&#39; understanding, ignoring decades of advance=
s in processor technology: microcode, deep pipelines, hyperthreading, specu=
lative execution, dynamic execution etc. Simplifying the machine model to m=
ake it easier to explain to students is not only patronizing, it does those=
 students a huge disservice.</div><span><div><br></div><div>On Tue, Mar 8, =
2016 at 4:32 PM, Hyman Rosen=C2=A0<span dir=3D"ltr">&lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"bazC-9RaBgAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">hyman...@gmail.com</a>&=
gt;</span>=C2=A0<wbr>wrote:<br><blockquote 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"><div dir=3D"ltr">A computer program is the means =
whereby a computer is instructed to carry out a computation.=C2=A0 Allowing=
 the meaning of parts of a program to be unspecified is a failure to provid=
e specific instructions to the computer, and to the extent that the author =
of the program did not mean this lack of specificity, is a trap for the aut=
hor and for all future users of the program.</div></blockquote></div><div><=
br></div></span><div>The meaning is fully specified. The behavior may not b=
e, but that is irrelevant; a program that fully specifies behavior would be=
 so inflexible as to be useless.=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&quot; 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"=
bazC-9RaBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;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"bazC-9RaBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit </blockquote></div></div>...</bloc=
kquote></div>

<p></p>

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

------=_Part_5872_396556930.1457525000386--
------=_Part_5871_1693810230.1457525000386--

.

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

On Wed, Mar 9, 2016 at 4:12 AM, Fabio Fracassi <f.fracassi@gmx.net> wrote:

>
>
> On 09/03/2016 09:36, Miro Knejp wrote:
>
> Am 09.03.2016 um 07:55 schrieb 'Edward Catmur' via ISO C++ Standard -
> Future Proposals:
>
> > If the compiler can't optimize as effectively because there are multipl=
e
> side-effects which it was previously reordering optimally but can no long=
er
> reorder optimally, then that seems like a potentially legitimate (if rare=
)
> scenario for concern. However, in that scenario, the semantics of the cod=
e
> were probably undefined anyways since OOE was undefined.
>
> Unspecified, not undefined. There is a huge difference.
>
> And that is? I may not be a native English speaker but every page on the
> internet tells me unspecified and undefined are synonyms. As they are in
> German and Czech so I'm really curious now. Would you please elaborate wh=
at
> the difference is?
>
>
> - unspecified behavior - means that out of several viable options the
> standard does not specify which to take, the compiler is at liberty to
> select any of the viable options, and is allowed to select a different on=
e
> at each run. [1]-=C2=A71.3.26
>

So the key difference is the program is not broken if it relies on
unspecified behavior (although that seems contradictory as the program
doesn't know exactly what it relies on)? Are these viable options dictated
by the Standard itself?

--=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/CALEPxfu2Wqeu4p4joOPj9u6uD8Z5AcvrEFjMjyF4ZzhK%3D=
5sZpw%40mail.gmail.com.

--001a114080c034b93f052d9cc280
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, Mar 9, 2016 at 4:12 AM, Fabio Fracassi <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:f.fracassi@gmx.net" target=3D"_blank">f.fracassi@gmx.net</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">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    <br>
    <br>
    <div>On 09/03/2016 09:36, Miro Knejp wrote:<br>
    </div>
    </span><blockquote type=3D"cite"><span class=3D"">
     =20
      Am 09.03.2016 um 07:55 schrieb &#39;Edward Catmur&#39; via ISO C++
      Standard - Future Proposals:<br>
      </span><span class=3D""><blockquote type=3D"cite">&gt; If the compile=
r can&#39;t optimize as effectively
        because there are multiple side-effects which it was previously
        reordering optimally but can no longer reorder optimally, then
        that seems like a potentially legitimate (if rare) scenario for
        concern. However, in that scenario, the semantics of the code
        were probably undefined anyways since OOE was undefined.
        <p dir=3D"ltr">Unspecified, not undefined. There is a huge
          difference. </p>
      </blockquote>
      And that is? I may not be a native English speaker but every page
      on the internet tells me unspecified and undefined are synonyms.
      As they are in German and Czech so I&#39;m really curious now. Would
      you please elaborate what the difference is?<br>
      <br>
    </span></blockquote>
    <br>- unspecified behavior - means that out of several viable options
    the standard does not specify which to take, the compiler is at
    liberty to select any of the viable options, and is allowed to
    select a different one at each run. [1]-=C2=A71.3.26<br></div></blockqu=
ote><div><br></div><div>So the key difference is the program is not broken =
if it relies on unspecified behavior (although that seems contradictory as =
the program doesn&#39;t know exactly what it relies on)? Are these viable o=
ptions dictated by the Standard itself?</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxfu2Wqeu4p4joOPj9u6uD8Z5AcvrEFjM=
jyF4ZzhK%3D5sZpw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfu2Wqeu4p=
4joOPj9u6uD8Z5AcvrEFjMjyF4ZzhK%3D5sZpw%40mail.gmail.com</a>.<br />

--001a114080c034b93f052d9cc280--

.

------=_Part_86_1341789505.1457535581175
Content-Type: multipart/alternative;
 boundary="----=_Part_87_1113868974.1457535581176"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8A=E5=8D=881:07:46=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tue, Mar 8, 2016 at 11:48 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>
> (Alternatives? Hmm... still ugly like C#'s scoped "using" if the right=20
> operand is used more than once and locality is wanted:)
>
>
> Ada got it right (of course).  Ada has boolean binary operators 'and' and=
=20
> 'or' which evaluate both sides and may be overloaded.  It also has=20
> short-circuiting forms 'and then' and 'or else' which cannot be overloade=
d.
>
> Yes, this design is better than the status quo.

Nevertheless, I want more. For example, for binary 'and', I want to=20
differentiate these variants (when needed):

Symentric, i.e. both operands will be evaluated, with deliberately=20
unspecified order, allowing swapping operands with no consequence;
Fold-like, i.e. both operands will be evaluated once exactly, in a=20
specified order;
Circuit, i.e. current builtin '&&'.

This is not only needed for operators. I recently wrote something like=20
signal combinator of boost.signals2, where I want to fold boolean results=
=20
as configurable predefined operations. I found std::any_of and std::all_of=
=20
are not enough since they do not guarantee how predicate would be evaluated=
=20
in such an example where side effects are significant.
=20

> As far as a cascade of pointers go, stop trying to be compact:
>
> auto p =3D ...
> if (p) {
>     auto q =3D p->...;
>     if (q) {
>         auto r  =3D q->...
>         if (r) {
>             r->...
> ...

Yep, pointers are the root evil here.
With an overloaded operator* for pointer which throw for null pointer value=
=20
before indirection, these lines will be cleaner. But actually it is worse.

--=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/3eb2d146-7670-43b8-9b6a-f9ebe16e6652%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=881:07:46=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>On Tue, Mar 8, 2016 at 11:48 AM, FrankHB1989 <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"ucAtVHhSBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">frank...@gmail.com</a>&gt;</span> wrote:<blockquote style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div>(Alternatives? Hmm... still ugly like C#&#39;s scoped &quot;using&quot;=
 if the right operand is used more than once and locality is wanted:)</div>=
</div></blockquote><div><br>Ada got it right (of course).=C2=A0 Ada has boo=
lean binary operators &#39;and&#39; and &#39;or&#39; which evaluate both si=
des and may be overloaded.=C2=A0 It also has short-circuiting forms &#39;an=
d then&#39; and &#39;or else&#39; which cannot be overloaded.<br><br></div>=
</div></div></div></blockquote><div>Yes, this design is better than the sta=
tus quo.<br><br>Nevertheless, I want more. For example, for binary &#39;and=
&#39;, I want to differentiate these variants (when needed):<br><br>Symentr=
ic, i.e. both operands will be evaluated, with deliberately unspecified ord=
er, allowing swapping operands with no consequence;<br>Fold-like, i.e. both=
 operands will be evaluated once exactly, in a specified order;<br>Circuit,=
 i.e. current builtin &#39;&amp;&amp;&#39;.<br><br>This is not only needed =
for operators. I recently wrote something like signal combinator of boost.s=
ignals2, where I want to fold boolean results as configurable predefined op=
erations. I found std::any_of and std::all_of are not enough since they do =
not guarantee how predicate would be evaluated in such an example where sid=
e effects are significant.<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"><div><div><div>As far as a cascade of poin=
ters go, stop trying to be compact:<br><br>auto p =3D ...<br>if (p) {<br>=
=C2=A0 =C2=A0 auto q =3D p-&gt;...;<br>=C2=A0 =C2=A0 if (q) {<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 auto r =C2=A0=3D q-&gt;...<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 if (r) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r-&gt;...</di=
v></div></div></div>...</blockquote><div>Yep, pointers are the root evil he=
re.<br>With an overloaded operator* for pointer which throw for null pointe=
r value before indirection, these lines will be cleaner. But actually it is=
 worse.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3eb2d146-7670-43b8-9b6a-f9ebe16e6652%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3eb2d146-7670-43b8-9b6a-f9ebe16e6652=
%40isocpp.org</a>.<br />

------=_Part_87_1113868974.1457535581176--
------=_Part_86_1341789505.1457535581175--

.

On 2016-03-08 18:06, Brent Friedman wrote:
> We have some code which uses a style like this for declaring UI elements:
>
> new Window().add(
>    new BorderElement(3_px).add(
>       new Scroller().add( new TextBox("Hello"), new Image("chat.png")  ),
>       new Hyperlink("help.html")
>     ) );
>
> Though the syntax is handy, you can imagine that expressions like this are
> really dangerous for any side-effects they might have.

Or... don't introduce side effects in widget creation. There should be
no reason I can't get the same effect by writing:

  auto const window = new Window();
  auto const image = new Image("chat.png");
  auto const text = new TextBox("Hello");
  auto const link = new Hyperlink("help.html");
  auto const scroll = new Scroller();
  auto const border = new BorderElement(3_px);

  border.add(scroll);
  scroll.add(text, image, link);
  window.add(border);

If that, or any other ordering, results in modified semantics, then IMHO
your API leaves something to be desired...

> There's a fair argument that this code shouldn't be written like this in
> C++ today

FWIW, I'll submit the above as a counterexample :-).

--
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/nbpe71%24i1s%241%40ger.gmane.org.

.

On 2016-03-09 07:22, Dilip Ranganathan wrote:
> So the key difference is the program is not broken if it relies on
> unspecified behavior (although that seems contradictory as the program
> doesn't know exactly what it relies on)?

No... a program that *relies on a specific choice regarding unspecified
behavior* is still broken, because the compiler can change its mind at
any time and for any reason. A program may, however, contain code that
*invokes* unspecified behavior without being broken. (Nearly all
existing programs do so, pre-C++17, via order of evaluation.)

A program that invokes Undefined Behavior (frequently abbreviated UB) is
*always* broken=C2=B9. UB means the compiler is free to pretend that code
doesn't exist, never executes, or to replace it with entirely different
code, and that anything can happen at run time. (Most compilers aren't
so evil as to replace UB with code to reformat your hard drive or launch
a nuclear strike, but those would be standard conforming options...)

(A program that relies on implementation defined behavior... relies on
implementation defined behavior. Whether that constitutes "broken" as
such is a matter of interpretation; at any rate, it's not portable. That
said, note that I believe it is still standards conforming for an
implementation to specify unspecified or undefined behavior.)

(=C2=B9 Technically. It *may* just happen to work anyway, but it's still
considered broken.)

> Are these viable options dictated by the Standard itself?

In general, I would assume so. They may also be implied, as I suspect is
the case (without reading through the standard) in order of evaluation.
The "options" in that case are "obviously" possible orderings.

--=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/nbpeo3%24smp%241%40ger.gmane.org.

.

------=_Part_555_27592966.1457539519818
Content-Type: multipart/alternative;
 boundary="----=_Part_556_327047640.1457539519818"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8B=E5=8D=888:23:02=EF=BC=8CDilip Ranganathan=E5=86=99=E9=81=93=EF=
=BC=9A
>
>
> On Wed, Mar 9, 2016 at 4:12 AM, Fabio Fracassi <f.fra...@gmx.net=20
> <javascript:>> wrote:
>
>>
>>
>> On 09/03/2016 09:36, Miro Knejp wrote:
>>
>> Am 09.03.2016 um 07:55 schrieb 'Edward Catmur' via ISO C++ Standard -=20
>> Future Proposals:
>>
>> > If the compiler can't optimize as effectively because there are=20
>> multiple side-effects which it was previously reordering optimally but c=
an=20
>> no longer reorder optimally, then that seems like a potentially legitima=
te=20
>> (if rare) scenario for concern. However, in that scenario, the semantics=
 of=20
>> the code were probably undefined anyways since OOE was undefined.=20
>>
>> Unspecified, not undefined. There is a huge difference.=20
>>
>> And that is? I may not be a native English speaker but every page on the=
=20
>> internet tells me unspecified and undefined are synonyms. As they are in=
=20
>> German and Czech so I'm really curious now. Would you please elaborate w=
hat=20
>> the difference is?
>>
>>
>> - unspecified behavior - means that out of several viable options the=20
>> standard does not specify which to take, the compiler is at liberty to=
=20
>> select any of the viable options, and is allowed to select a different o=
ne=20
>> at each run. [1]-=C2=A71.3.26
>>
>
> So the key difference is the program is not broken if it relies on=20
> unspecified behavior (although that seems contradictory as the program=20
> doesn't know exactly what it relies on)? Are these viable options dictate=
d=20
> by the Standard itself?
> =20
>
In C, if a program has undefined behavior, it is either nonportable or=20
erroneous. If not broken, you have to make sure it is relying on some=20
extensions (e.g. POSIX) which guarantee the behavior is predicable.=20
(However some undefined behavior may remain in such extensions.) Programs=
=20
rely on such behavior not guaranteed by ISO C is not strictly conforming,=
=20
but can be still "C" program allowed by the specification of C. Thus they=
=20
may be not broken.
ISO C++ has no notion of "extension" as ISO C. Undefined just means broken=
=20
in general, or you have to make sure it is using a dialect which is not=20
compatible to ISO C++. It is either broken, or it is not written in C++.
One important fact is C/C++ compilers (as conforming implementations) are=
=20
permitted to assume undefined behavior never occur in the programs they=20
translate. On the other hand, no unspecified behavior has such property, by=
=20
definition.
Note that since C supports extension, there are people strongly against the=
=20
utilization of undefined behavior (mainly for optimization purpose) in C=20
compilers, but this seems have little effect on C++.
=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/b638fe8f-cc90-49be-b483-f82c37f5bf26%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=888:23:02=EF=BC=8CDilip Ranganat=
han=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"><div><br><div class=3D"gmail_quote">On Wed, Mar 9, 2016 at=
 4:12 AM, Fabio Fracassi <span dir=3D"ltr">&lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"7Y0dLoORBgAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;">f.fra...@gmx.net</a>&gt;</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">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span>
    <br>
    <br>
    <div>On 09/03/2016 09:36, Miro Knejp wrote:<br>
    </div>
    </span><blockquote type=3D"cite"><span>
     =20
      Am 09.03.2016 um 07:55 schrieb &#39;Edward Catmur&#39; via ISO C++
      Standard - Future Proposals:<br>
      </span><span><blockquote type=3D"cite">&gt; If the compiler can&#39;t=
 optimize as effectively
        because there are multiple side-effects which it was previously
        reordering optimally but can no longer reorder optimally, then
        that seems like a potentially legitimate (if rare) scenario for
        concern. However, in that scenario, the semantics of the code
        were probably undefined anyways since OOE was undefined.
        <p dir=3D"ltr">Unspecified, not undefined. There is a huge
          difference. </p>
      </blockquote>
      And that is? I may not be a native English speaker but every page
      on the internet tells me unspecified and undefined are synonyms.
      As they are in German and Czech so I&#39;m really curious now. Would
      you please elaborate what the difference is?<br>
      <br>
    </span></blockquote>
    <br>- unspecified behavior - means that out of several viable options
    the standard does not specify which to take, the compiler is at
    liberty to select any of the viable options, and is allowed to
    select a different one at each run. [1]-=C2=A71.3.26<br></div></blockqu=
ote><div><br></div><div>So the key difference is the program is not broken =
if it relies on unspecified behavior (although that seems contradictory as =
the program doesn&#39;t know exactly what it relies on)? Are these viable o=
ptions dictated by the Standard itself?</div><div>=C2=A0</div></div></div><=
/div></blockquote><div>In C, if a program has undefined behavior, it is eit=
her nonportable or erroneous. If not broken, you have to make sure it is re=
lying on some extensions (e.g. POSIX) which guarantee the behavior is predi=
cable. (However some undefined behavior may remain in such extensions.) Pro=
grams rely on such behavior not guaranteed by ISO C is not strictly conform=
ing, but can be still &quot;C&quot; program allowed by the specification of=
 C. Thus they may be not broken.<br>ISO C++ has no notion of &quot;extensio=
n&quot; as ISO C. Undefined just means broken in general, or you have to ma=
ke sure it is using a dialect which is not compatible to ISO C++. It is eit=
her broken, or it is not written in C++.<br>One important fact is C/C++ com=
pilers (as conforming implementations) are permitted to assume undefined be=
havior never occur in the programs they translate. On the other hand, no un=
specified behavior has such property, by definition.<br>Note that since C s=
upports extension, there are people strongly against the utilization of und=
efined behavior (mainly for optimization purpose) in C compilers, but this =
seems have little effect on C++.<br>=C2=A0<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b638fe8f-cc90-49be-b483-f82c37f5bf26%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b638fe8f-cc90-49be-b483-f82c37f5bf26=
%40isocpp.org</a>.<br />

------=_Part_556_327047640.1457539519818--
------=_Part_555_27592966.1457539519818--

.

------=_Part_702_645112929.1457541093036
Content-Type: multipart/alternative;
 boundary="----=_Part_703_1164556651.1457541093036"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8A=E5=8D=8812:33:07=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> A computer program is the means whereby a computer is instructed to carry=
=20
> out a computation.  Allowing the meaning of parts of a program to be=20
> unspecified is a failure to provide specific instructions to the computer=
,=20
> and to the extent that the author of the program did not mean this lack o=
f=20
> specificity, is a trap for the author and for all future users of the=20
> program.
>
> I'm strongly against at this point. We were talking programs which are no=
t=20
necessarily implemented by computation in machines. A specification of a=20
general-purposed language should be able to describe programs actually not=
=20
physically implementable, e.g. a program never terminate. Otherwise you=20
should eliminate all undefined behavior at first.

Note, it is the semantics of parts of programs is guaranteed to be=20
"unspecified", as well as some predictable behavior. Language rules can not=
=20
specify the actually meaning of programs totally. The latter depends on=20
your intent and use.

And this for the dubious prospect that the program may sometimes run a=20
> little faster, and for the dubious pleasure of mocking the author for=20
> failing to notice the problem.  There is nothing bad or ugly about relyin=
g=20
> on order of evaluation.  The badness and ugliness is in taking an error i=
n=20
> programming language design and elevating that error into a principle.
>
> If a design makes it always a lot harder to implement faster programs and=
=20
brings nothing more about expressiveness or abstraction, that design is=20
problematic. There is nothing bad or ugly relying on order of evaluation=20
*intentionally*, but it is absolutely bad to blur the situation of being=20
confident and ignorant, also definitely ugly to encourage innocent users to=
=20
do so by specification which takes away freedom of some others.

On Tue, Mar 8, 2016 at 10:43 AM, Miro Knejp <miro....@gmail.com=20
> <javascript:>> wrote:
>
> Am 08.03.2016 um 15:32 schrieb FrankHB1989:
>
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UT=
C+8=E4=B8=8A=E5=8D=883:56:12=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A=
=20
>
> Am 04.03.2016 um 13:04 schrieb 'Edward Catmur' via ISO C++ Standard -=20
> Future Proposals:
>
>
> On 4 Mar 2016 12:29, "Miro Knejp" <miro....@gmail.com> wrote:
> >
> > People have wildly different expectations, and that largely depends on=
=20
> what they start programming with. And people who have never programmed=20
> before usually have expectations that have no connection to the technical=
=20
> reality. Those who grow up speaking and writing a left-to-right language=
=20
> have it ingrained in their head that all sequences of things are=20
> let-to-right as that is the direction they read and write in. In math cla=
ss=20
> they are given the exercise f(g(x) + h(x)) and how do they intuitively=20
> solve it? They calculate a=3Dg(x) first, then b=3Dh(x), then c=3Da+b, the=
n f(c).=20
> Try getting rid of this intuition after applying it for several years=20
> during the phase of your live where the brain solidifies such patterns.=
=20
> They expect the programming language to work the same because programming=
=20
> and math are very closely related, and all the modern languages actually=
=20
> *do* fulfill this expectation.
> >
>
> What do they do when given f(x) + g(x) * h(x)?
>
> Mathematical formulae - which programming language expressions model - do=
=20
> not have side effects, so intermediate results can be computed in any=20
> order.=20
>
> That's not the point. It doesn't matter whether math formulas have no sid=
e=20
> effects or that they can be evaluated in any order. What matters is the=
=20
> underlying psychology of the people who do the exercise, and later the=20
> programming course. If they're used to a certain way of solving these=20
> problems and have trained that during a critical phase of brain develomen=
t,=20
> they apply it to everything. It's a pattern, and our brain is very good a=
t=20
> identifying and applying patterns, but horrifically bad at abandoning=20
> existing patterns.
>
>
> The syntactic design of many ALGOL-derived languages are clearly effected=
=20
> by the math notation. Learners of such languages are often required have=
=20
> background knowledge about such syntax style. So the underlying psycholog=
y=20
> of most people should be similar at first. When there are semantics stuff=
,=20
> things get complicated, because there is nothing "side effects" in=20
> traditional math they have learned. Syntax of math can be considered bad=
=20
> pattern, but the fresh rules of semantics should be not.
>
> Back then only few people did study computer science, and those were=20
> usually like-minded people (i.e. nerds) who came into university with ton=
s=20
> of similar prior knowledge. Today we have millions of students leaving=20
> school at 18 and entering computer science studies since it became=20
> mainstream. Today these students have vastly different backgrounds in=20
> education and interests and it's dangerous to assume otherwise. Many of=
=20
> them had no prior exposure to programming at all, but that doesn't=20
> automatically mean they cannot become great programmers. We shouldn't=20
> "require" any further background knowledge from students than what they g=
et=20
> from the school or university curriculums. The easier we can make it for=
=20
> people to understand the language and the underlying concepts, apply it o=
n=20
> their own, and keep them motivated and intersted the better for the=20
> industry. There aren't going to be less programming jobs in the future, s=
o=20
> much is pretty much certain. And I'd prefer these graduates to not be=20
> scared of C++ but to proudly say it is one of their favorites. These peop=
le=20
> also need to have a proper understanding of the software+hardware=20
> interaction (something I see missing a lot today), which they won't get i=
f=20
> they are only exposed to C# or Java because they abandoned C++ due to its=
=20
> inconsistencies and frustration points.
>
> Any reasonably competent student will exploit this to perform CSE and=20
> other rewriting tricks to simplify the computation, so the similar tricks=
=20
> the compiler performs should be intimately familiar.=20
>
> They do CSE because it saves *them* work, because it saves *them* time on=
=20
> exams, but a machine doesn't care about that and most class or home=20
> exercises finish computing quickly enough that execution time doesn't=20
> matter. I argue that most beginner programming students pay optimization=
=20
> absolutely no attention and probably don't even know such a thing exists.=
=20
> Those with prior experience, yes, but the majority don't until they=20
> actually get into courses that deal with data structures, algorithms,=20
> complexities and code transforming optimizations, but until they receive=
=20
> (and understand) that knowledge they may have already decided that C++ is=
 a=20
> stupid language and that Java is all the awesomeness.
>
>
> Nothing wrong.
>
> What do you mean by that? That there's nothing wrong with young students=
=20
> being frustrated by C++ and not explore it further and instead join the=
=20
> crowd of ignorant developers who get a panic attack when hearing the word=
=20
> "pointer"? I want as many computer science students as possible to like a=
nd=20
> use C++ because that includes the understanding of the underlying machine=
=20
> interfaction engineering principles they may never learn in any of those=
=20
> fancy higher-level languages.
>
> If young people don't want to learn and use C++ there is either a problem=
=20
> with the language, or the theacher, or both. The more compilcated the rul=
es=20
> get and the more exceptions there are the more difficult we make it for=
=20
> newcomers.
>
> Then, too, when they're learning fundamentals of programming languages,=
=20
> they will discover that the order in which term rewriting rules are appli=
ed=20
> can affect, if not the result, then certainly how long it takes to reach=
=20
> the result and even whether the result is reached at all (for weakly=20
> normalizing terms).
>
> This kind of transformation is only dealt with in courses that actually=
=20
> teach the topic of code transforming optimizations. But often theses=20
> courses are considered advanced, and sometimes even optional. The topic o=
f=20
> "performance" is typically only touched on in courses dealing with data=
=20
> structures and algorithmic complexity, but those exercises don't have=20
> execution times which are saved by subexpression reordering, they are=20
> tailored specifically to show the difference betwen a hash map and a link=
ed=20
> list.
>
>
> Still nothing wrong.=20
>
> So I don't believe that programming novices expect any particular=20
> evaluation order, irrespective of what human languages they speak.=20
>
> Don't underestimate the impact a language can have on how people think.=
=20
> There is evidence pointing in the direction that native one speaks langua=
ge=20
> does influence the way of thinking and problem solving (see the weak=20
> Sapir-Whorf hypothesis) and that it even changes how a bilingual thinks=
=20
> when switching between languages.
>
> They can't find the difference between natural languag
>
> ...

--=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/96b3cdad-b335-49e4-bb34-57574f8c1793%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:33:07=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">A computer program is the means whereby a computer is instruc=
ted to carry out a computation.=C2=A0 Allowing the meaning of parts of a pr=
ogram to be unspecified is a failure to provide specific instructions to th=
e computer, and to the extent that the author of the program did not mean t=
his lack of specificity, is a trap for the author and for all future users =
of the program.<div><br></div></div></blockquote><div>I&#39;m strongly agai=
nst at this point. We were talking programs which are not necessarily imple=
mented by computation in machines. A specification of a general-purposed la=
nguage should be able to describe programs actually not physically implemen=
table, e.g. a program never terminate. Otherwise you should eliminate all u=
ndefined behavior at first.<br><br>Note, it is the semantics of parts of pr=
ograms is guaranteed to be &quot;unspecified&quot;, as well as some predict=
able behavior. Language rules can not specify the actually meaning of progr=
ams totally. The latter depends on your intent and use.<br><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><div>And=
 this for the dubious prospect that the program may sometimes run a little =
faster, and for the dubious pleasure of mocking the author for failing to n=
otice the problem.=C2=A0 There is nothing bad or ugly about relying on orde=
r of evaluation.=C2=A0 The badness and ugliness is in taking an error in pr=
ogramming language design and elevating that error into a principle.</div><=
/div><div><br></div></blockquote><div>If a design makes it always a lot har=
der to implement faster programs and brings nothing more about expressivene=
ss or abstraction, that design is <span class=3D"op_dict3_font24 op_dict3_m=
arginRight">problematic</span>. There is nothing bad or ugly relying on ord=
er of evaluation <i>intentionally</i>, but it is absolutely bad to blur <sp=
an class=3D"op_dict3_font24 op_dict3_marginRight">the situation of being co=
nfident and ignorant, also </span><span class=3D"op_dict3_font24 op_dict3_m=
arginRight"><span class=3D"op_dict3_font24 op_dict3_marginRight">definitely=
 </span>ugly to encourage innocent users to do so by specification which ta=
kes away freedom of some others.</span><br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div><div>On Tue, Mar 8, 2016 at 10:43 AM, Miro Knej=
p <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"mB4qQJRQBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">miro....@gmail.com</a>&gt;</span> wrote:<br><blockquote =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF"><span>
    Am 08.03.2016 um 15:32 schrieb FrankHB1989:<br>
    <blockquote>
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2016=E5=B9=B43=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=
=AD UTC+8=E4=B8=8A=E5=8D=883:56:12=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=
=BC=9A
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF"> Am 04.03.2016 um 13:04
            schrieb &#39;Edward Catmur&#39; via ISO C++ Standard - Future
            Proposals:<br>
            <blockquote>
              <p dir=3D"ltr"><br>
                On 4 Mar 2016 12:29, &quot;Miro Knejp&quot; &lt;<a rel=3D"n=
ofollow"></a><a>miro....@gmail.com</a>&gt;

                wrote:<br>
                &gt;<br>
                &gt; People have wildly different expectations, and that
                largely depends on what they start programming with. And
                people who have never programmed before usually have
                expectations that have no connection to the technical
                reality. Those who grow up speaking and writing a
                left-to-right language have it ingrained in their head
                that all sequences of things are let-to-right as that is
                the direction they read and write in. In math class they
                are given the exercise f(g(x) + h(x)) and how do they
                intuitively solve it? They calculate a=3Dg(x) first, then
                b=3Dh(x), then c=3Da+b, then f(c). Try getting rid of this
                intuition after applying it for several years during the
                phase of your live where the brain solidifies such
                patterns. They expect the programming language to work
                the same because programming and math are very closely
                related, and all the modern languages actually *do*
                fulfill this expectation.<br>
                &gt;</p>
              <p dir=3D"ltr">What do they do when given f(x) + g(x) *
                h(x)?</p>
              <p dir=3D"ltr">Mathematical formulae - which programming
                language expressions model - do not have side effects,
                so intermediate results can be computed in any order. </p>
            </blockquote>
            That&#39;s not the point. It doesn&#39;t matter whether math
            formulas have no side effects or that they can be evaluated
            in any order. What matters is the underlying psychology of
            the people who do the exercise, and later the programming
            course. If they&#39;re used to a certain way of solving these
            problems and have trained that during a critical phase of
            brain develoment, they apply it to everything. It&#39;s a
            pattern, and our brain is very good at identifying and
            applying patterns, but horrifically bad at abandoning
            existing patterns.<br>
          </div>
        </blockquote>
        <div><br>
          The syntactic design of many ALGOL-derived languages are
          clearly effected by the math notation. Learners of such
          languages are often required have background knowledge about
          such syntax style. So the underlying psychology of most people
          should be similar at first. When there are semantics stuff,
          things get complicated, because there is nothing &quot;side
          effects&quot; in traditional math they have learned. Syntax of ma=
th
          can be considered bad pattern, but the fresh rules of
          semantics should be not.<br>
        </div>
      </div>
    </blockquote></span>
    Back then only few people did study computer science, and those were
    usually like-minded people (i.e. nerds) who came into university
    with tons of similar prior knowledge. Today we have millions of
    students leaving school at 18 and entering computer science studies
    since it became mainstream. Today these students have vastly
    different backgrounds in education and interests and it&#39;s dangerous
    to assume otherwise. Many of them had no prior exposure to
    programming at all, but that doesn&#39;t automatically mean they cannot
    become great programmers. We shouldn&#39;t &quot;require&quot; any furt=
her
    background knowledge from students than what they get from the
    school or university curriculums. The easier we can make it for
    people to understand the language and the underlying concepts, apply
    it on their own, and keep them motivated and intersted the better
    for the industry. There aren&#39;t going to be less programming jobs in
    the future, so much is pretty much certain. And I&#39;d prefer these
    graduates to not be scared of C++ but to proudly say it is one of
    their favorites. These people also need to have a proper
    understanding of the software+hardware interaction (something I see
    missing a lot today), which they won&#39;t get if they are only exposed
    to C# or Java because they abandoned C++ due to its inconsistencies
    and frustration points.<span><br>
    <blockquote>
      <div dir=3D"ltr">
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF">
            <blockquote>
              <p dir=3D"ltr">Any reasonably competent student will exploit
                this to perform CSE and other rewriting tricks to
                simplify the computation, so the similar tricks the
                compiler performs should be intimately familiar. </p>
            </blockquote>
            They do CSE because it saves *them* work, because it saves
            *them* time on exams, but a machine doesn&#39;t care about that
            and most class or home exercises finish computing quickly
            enough that execution time doesn&#39;t matter. I argue that mos=
t
            beginner programming students pay optimization absolutely no
            attention and probably don&#39;t even know such a thing exists.
            Those with prior experience, yes, but the majority don&#39;t
            until they actually get into courses that deal with data
            structures, algorithms, complexities and code transforming
            optimizations, but until they receive (and understand) that
            knowledge they may have already decided that C++ is a stupid
            language and that Java is all the awesomeness.<br>
          </div>
        </blockquote>
        <div><br>
          Nothing wrong.<br>
        </div>
      </div>
    </blockquote></span>
    What do you mean by that? That there&#39;s nothing wrong with young
    students being frustrated by C++ and not explore it further and
    instead join the crowd of ignorant developers who get a panic attack
    when hearing the word &quot;pointer&quot;? I want as many computer scie=
nce
    students as possible to like and use C++ because that includes the
    understanding of the underlying machine interfaction engineering
    principles they may never learn in any of those fancy higher-level
    languages.<br>
    <br>
    If young people don&#39;t want to learn and use C++ there is either a
    problem with the language, or the theacher, or both. The more
    compilcated the rules get and the more exceptions there are the more
    difficult we make it for newcomers.<span><br>
    <blockquote>
      <div dir=3D"ltr">
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF">
            <blockquote>
              <p dir=3D"ltr">Then, too, when they&#39;re learning fundament=
als
                of programming languages, they will discover that the
                order in which term rewriting rules are applied can
                affect, if not the result, then certainly how long it
                takes to reach the result and even whether the result is
                reached at all (for weakly normalizing terms).</p>
            </blockquote>
            This kind of transformation is only dealt with in courses
            that actually teach the topic of code transforming
            optimizations. But often theses courses are considered
            advanced, and sometimes even optional. The topic of
            &quot;performance&quot; is typically only touched on in courses
            dealing with data structures and algorithmic complexity, but
            those exercises don&#39;t have execution times which are saved
            by subexpression reordering, they are tailored specifically
            to show the difference betwen a hash map and a linked list.<br>
          </div>
        </blockquote>
        <div><br>
          Still nothing wrong. <br>
        </div>
        <blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF">
            <blockquote>
              <p dir=3D"ltr"> So I don&#39;t believe that programming novic=
es
                expect any particular evaluation order, irrespective of
                what human languages they speak. </p>
            </blockquote>
            Don&#39;t underestimate the impact a language can have on how
            people think. There is evidence pointing in the direction
            that native one speaks language does influence the way of
            thinking and problem solving (see the weak Sapir-Whorf
            hypothesis) and that it even changes how a bilingual thinks
            when switching between languages.<br>
            <br>
          </div>
        </blockquote>
        <div>They can&#39;t find the difference between natural languag</di=
v></div></blockquote></span></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/96b3cdad-b335-49e4-bb34-57574f8c1793%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/96b3cdad-b335-49e4-bb34-57574f8c1793=
%40isocpp.org</a>.<br />

------=_Part_703_1164556651.1457541093036--
------=_Part_702_645112929.1457541093036--

.

------=_Part_832_1899787381.1457542143916
Content-Type: multipart/alternative;
 boundary="----=_Part_833_272496683.1457542143917"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8A=E5=8D=881:40:06=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 08.03.2016 um 18:10 schrieb FrankHB1989:
>
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UT=
C+8=E4=B8=8A=E5=8D=881:43:26=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A=
=20
>>
>> Am 06.03.2016 um 17:43 schrieb Patrice Roy:=20
>> > I know people take this issue to heart, but I think it would be=20
>> > preferable for the debate if we collectively kept wording =C2=ABcalmed=
=20
>> down=C2=BB.=20
>> >=20
>> > There are C++ idioms based on evaluation order, such as =C2=ABif (p &&=
=20
>> > p->f()) for some pointer p that checks whether it's null before using=
=20
>> > it. I doubt anyone would claim that such idioms are =C2=ABa bad thing=
=C2=BB as=20
>> > they are integrated in practice and have been for decades. It becomes=
=20
>> > annoying when someone overloads operator&& but apart from this, it=20
>> > works well and sets a nice precedent of code relying on evaluation=20
>> > order. There are others, of course, particularly with respect to=20
>> > operators.=20
>> >=20
>> > I think the point that some have made that they feel f(g(), h())=20
>> > should have a well-defined order for g() and h() is clear. I don't=20
>> > have to agree with it but it's a clear point, and we'll most probably=
=20
>> > hear it in the discussions we'll have in Oulu as the proposal for=20
>> > evaluation order should be brought up there. Maybe it will convince=20
>> > people better than it convinced me, we'll see. I have never seen the=
=20
>> > undefined ordering of g() and h() in such a case as expert-level=20
>> > knowledge (most of my students, if not all, learn that from the=20
>> > start), but I believe those who say their experience differs.=20
>> Unfortunately we cannot ensure all students are tought the same things=
=20
>> and come out of college with the same level of knowledge. I believe the=
=20
>> fewer rules there are they have to remember the more time and brainpower=
=20
>> they have available to solve the actual problem instead of fighting the=
=20
>> language, making the whole learning process less frustrating and more=20
>> enjoyable.=20
>>
> If you want fewer rules, you'd prefer unspecified order rules than=20
> proposed wording.
>
> >=20
>> > I understand the potential efficiency loss argument with respect to=20
>> > the current undefined ordering. I'd need to see numbers, though, to be=
=20
>> > convinced. If we get [[pure]], this argument will be strengthened a=20
>> > bit (we could not evaluate sume functions that have been memoized, for=
=20
>> > example), but that's an =C2=ABif=C2=BB.=20
>> >=20
>> > The fact that depending on this newly-defined order risks becoming=20
>> > idiomatic is what worries me, and many others. As stated previously,=
=20
>> > this would make such things as f(i++,i++) acceptable practice with=20
>> > respect to the standard (even if not according to many coding=20
>> > standards) given that operator++(int) can be overloaded.=20
>> I don't understand the worry. As you have stated yourself, depending on=
=20
>> "if(p && p->f())" is considered OK, but why? Because it *is* OK or=20
>> because it has been done for decades and people got used to it?
>
> Nope. This is a classic comprise about weakness of type system and some=
=20
> other subtle rules.
> =20
>
>> The=20
>> current proposal suggests overloaded operators to get the same order as=
=20
>> the builtin ones, so that trap would go away. "f(g(), h())" is currently=
=20
>> bad because it is undefined and nondeterministic, but if that changes=20
>> and it *is* defined and deterministic, why is it still bad?
>
> Because the change of rules itself is bad. There would be no way to=20
> express nondeterminstic evaluation, which is intended sometimes.
>
> Please show an example where it is intended and why it is important that=
=20
> it is nondeterministic.
>
> constexpr int f(int x, int y)
{
  return x + y;
}
constexpr int g()
{
//...
}
constexpr int h()
{
//...
}

f(g(), h()) // Stop wasting time on guessing whether you should refactor it=
=20
by swapping the arguments or not!
=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/eef6fd1f-0eeb-4ae7-a7e4-b27e1504970e%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=881:40:06=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 08.03.2016 um 18:10 schrieb FrankHB1989:<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        =E5=9C=A8 2016=E5=B9=B43=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=80 UTC+8=E4=B8=8A=E5=8D=881:43:26=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.8=
ex;border-left:1px #ccc solid;padding-left:1ex">Am
          06.03.2016 um 17:43 schrieb Patrice Roy:
          <br>
          &gt; I know people take this issue to heart, but I think it
          would be <br>
          &gt; preferable for the debate if we collectively kept wording
          =C2=ABcalmed down=C2=BB.
          <br>
          &gt;
          <br>
          &gt; There are C++ idioms based on evaluation order, such as
          =C2=ABif (p &amp;&amp; <br>
          &gt; p-&gt;f()) for some pointer p that checks whether it&#39;s
          null before using <br>
          &gt; it. I doubt anyone would claim that such idioms are =C2=ABa
          bad thing=C2=BB as <br>
          &gt; they are integrated in practice and have been for
          decades. It becomes <br>
          &gt; annoying when someone overloads operator&amp;&amp; but
          apart from this, it <br>
          &gt; works well and sets a nice precedent of code relying on
          evaluation <br>
          &gt; order. There are others, of course, particularly with
          respect to <br>
          &gt; operators.
          <br>
          &gt;
          <br>
          &gt; I think the point that some have made that they feel
          f(g(), h()) <br>
          &gt; should have a well-defined order for g() and h() is
          clear. I don&#39;t <br>
          &gt; have to agree with it but it&#39;s a clear point, and we&#39=
;ll
          most probably <br>
          &gt; hear it in the discussions we&#39;ll have in Oulu as the
          proposal for <br>
          &gt; evaluation order should be brought up there. Maybe it
          will convince <br>
          &gt; people better than it convinced me, we&#39;ll see. I have
          never seen the <br>
          &gt; undefined ordering of g() and h() in such a case as
          expert-level <br>
          &gt; knowledge (most of my students, if not all, learn that
          from the <br>
          &gt; start), but I believe those who say their experience
          differs.
          <br>
          Unfortunately we cannot ensure all students are tought the
          same things <br>
          and come out of college with the same level of knowledge. I
          believe the <br>
          fewer rules there are they have to remember the more time and
          brainpower <br>
          they have available to solve the actual problem instead of
          fighting the <br>
          language, making the whole learning process less frustrating
          and more <br>
          enjoyable.
          <br>
        </blockquote>
        <div>If you want fewer rules, you&#39;d prefer unspecified order
          rules than proposed wording.<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">&gt;
          <br>
          &gt; I understand the potential efficiency loss argument with
          respect to <br>
          &gt; the current undefined ordering. I&#39;d need to see numbers,
          though, to be <br>
          &gt; convinced. If we get [[pure]], this argument will be
          strengthened a <br>
          &gt; bit (we could not evaluate sume functions that have been
          memoized, for <br>
          &gt; example), but that&#39;s an =C2=ABif=C2=BB.
          <br>
          &gt;
          <br>
          &gt; The fact that depending on this newly-defined order risks
          becoming <br>
          &gt; idiomatic is what worries me, and many others. As stated
          previously, <br>
          &gt; this would make such things as f(i++,i++) acceptable
          practice with <br>
          &gt; respect to the standard (even if not according to many
          coding <br>
          &gt; standards) given that operator++(int) can be overloaded.
          <br>
          I don&#39;t understand the worry. As you have stated yourself,
          depending on <br>
          &quot;if(p &amp;&amp; p-&gt;f())&quot; is considered OK, but why?
          Because it *is* OK or <br>
          because it has been done for decades and people got used to
          it?</blockquote>
        <div>Nope. This is a classic comprise about weakness of type
          system and some other subtle rules.<br>
          =C2=A0</div>
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">The <br>
          current proposal suggests overloaded operators to get the same
          order as <br>
          the builtin ones, so that trap would go away. &quot;f(g(), h())&q=
uot; is
          currently <br>
          bad because it is undefined and nondeterministic, but if that
          changes <br>
          and it *is* defined and deterministic, why is it still bad?</bloc=
kquote>
        <div>Because the change of rules itself is bad. There would be
          no way to express nondeterminstic evaluation, which is
          intended sometimes.<br>
        </div>
      </div>
    </blockquote>
    Please show an example where it is intended and why it is important
    that it is nondeterministic.<br>
    <br></div></blockquote><div>constexpr int f(int x, int y)<br>{<br>=C2=
=A0 return x + y;<br>}<br>constexpr int g()<br>{<br>//...<br>}<br>constexpr=
 int h()<br>{<br>//...<br>}<br><br>f(g(), h()) // Stop wasting time on gues=
sing whether you should refactor it by swapping the arguments or not!<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eef6fd1f-0eeb-4ae7-a7e4-b27e1504970e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eef6fd1f-0eeb-4ae7-a7e4-b27e1504970e=
%40isocpp.org</a>.<br />

------=_Part_833_272496683.1457542143917--
------=_Part_832_1899787381.1457542143916--

.

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

On Wed, Mar 9, 2016 at 11:31 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:

> =E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8A=E5=8D=8812:33:07=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> A computer program is the means whereby a computer is instructed to carr=
y
>> out a computation.  Allowing the meaning of parts of a program to be
>> unspecified is a failure to provide specific instructions to the compute=
r,
>> and to the extent that the author of the program did not mean this lack =
of
>> specificity, is a trap for the author and for all future users of the
>> program.
>>
>> I'm strongly against at this point. We were talking programs which are
> not necessarily implemented by computation in machines. A specification o=
f
> a general-purposed language should be able to describe programs actually
> not physically implementable, e.g. a program never terminate. Otherwise y=
ou
> should eliminate all undefined behavior at first.
>

Why would you want such a thing?  Or rather, why would you want such a
thing in the context of a programming language that is intended for writing
programs that are executed?  There are plenty of pidgin languages that
authors of computer science papers use to write pseudocode.  C++ isn't one
of them.  And what is wrong with a program that never terminates?  Many
servers are written like that, for example.



> Note, it is the semantics of parts of programs is guaranteed to be
> "unspecified", as well as some predictable behavior. Language rules can n=
ot
> specify the actually meaning of programs totally. The latter depends on
> your intent and use.
>

How can a program running on a computer possibly discern my intent?  I
express my intent by writing the program.  To the extent that the
programming language allows me to write apparent but non-obligatory intent,
it is creating a trap that will lead me to write programs that do not do
what I want them to do, and worse, programs that appear to do what I want
them to do now, but arbitrarily change their behavior sometime in the
future.

I cannot fathom why anyone would want such a thing, but I accept that there
are people who do.  Those people must be fought, for the good of the
community.


And this for the dubious prospect that the program may sometimes run a
>> little faster, and for the dubious pleasure of mocking the author for
>> failing to notice the problem.  There is nothing bad or ugly about relyi=
ng
>> on order of evaluation.  The badness and ugliness is in taking an error =
in
>> programming language design and elevating that error into a principle.
>>
>> If a design makes it always a lot harder to implement faster programs an=
d
> brings nothing more about expressiveness or abstraction, that design is
> problematic. There is nothing bad or ugly relying on order of evaluation
> *intentionally*, but it is absolutely bad to blur the situation of being
> confident and ignorant, also definitely ugly to encourage innocent users
> to do so by specification which takes away freedom of some others.
>

Specifying order of evaluation does not make it a lot harder to implement
faster programs.
Specifying order of evaluation increases expressiveness because it makes
programs legal that are now illegal.
The combination of confidence and ignorance accrues to those people who
insist that the evil consequences of failing to specify order of evaluation
can be mitigated by exhortation and review.
Specifying order of evaluation does not take away anyone's 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/CAHSYqdY5u10X55Ujs5cMxPGwoFZJMmW%2BLHLwztZ4fA-zQ=
3Sxjw%40mail.gmail.com.

--001a1143f1541c5b84052da3f09c
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, Mar 9, 2016 at 11:31 AM, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.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">=E5=9C=
=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=
=B8=8A=E5=8D=8812:33:07=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">A comp=
uter program is the means whereby a computer is instructed to carry out a c=
omputation.=C2=A0 Allowing the meaning of parts of a program to be unspecif=
ied is a failure to provide specific instructions to the computer, and to t=
he extent that the author of the program did not mean this lack of specific=
ity, is a trap for the author and for all future users of the program.<div>=
<br></div></div></blockquote></span><div>I&#39;m strongly against at this p=
oint. We were talking programs which are not necessarily implemented by com=
putation in machines. A specification of a general-purposed language should=
 be able to describe programs actually not physically implementable, e.g. a=
 program never terminate. Otherwise you should eliminate all undefined beha=
vior at first.<br></div></div></blockquote><div><br>Why would you want such=
 a thing?=C2=A0 Or rather, why would you want such a thing in the context o=
f a programming language that is intended for writing programs that are exe=
cuted?=C2=A0 There are plenty of pidgin languages that authors of computer =
science papers use to write pseudocode.=C2=A0 C++ isn&#39;t one of them.=C2=
=A0 And what is wrong with a program that never terminates?=C2=A0 Many serv=
ers are written like that, for example.<br><br>=C2=A0</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>Note, it is the semantics of parts of =
programs is guaranteed to be &quot;unspecified&quot;, as well as some predi=
ctable behavior. Language rules can not specify the actually meaning of pro=
grams totally. The latter depends on your intent and use.<br></div></div></=
blockquote><div><br>How can a program running on a computer possibly discer=
n my intent?=C2=A0 I express my intent by writing the program.=C2=A0 To the=
 extent that the programming language allows me to write apparent but non-o=
bligatory intent, it is creating a trap that will lead me to write programs=
 that do not do what I want them to do, and worse, programs that appear to =
do what I want them to do now, but arbitrarily change their behavior someti=
me in the future.<br><br>I cannot fathom why anyone would want such a thing=
, but I accept that there are people who do.=C2=A0 Those people must be fou=
ght, for the good of the community.<br><br><br></div><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""><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div></div><div>And this for the dubious prospect =
that the program may sometimes run a little faster, and for the dubious ple=
asure of mocking the author for failing to notice the problem.=C2=A0 There =
is nothing bad or ugly about relying on order of evaluation.=C2=A0 The badn=
ess and ugliness is in taking an error in programming language design and e=
levating that error into a principle.</div></div><div><br></div></blockquot=
e></span><div>If a design makes it always a lot harder to implement faster =
programs and brings nothing more about expressiveness or abstraction, that =
design is <span>problematic</span>. There is nothing bad or ugly relying on=
 order of evaluation <i>intentionally</i>, but it is absolutely bad to blur=
 <span>the situation of being confident and ignorant, also </span><span><sp=
an>definitely </span>ugly to encourage innocent users to do so by specifica=
tion which takes away freedom of some others.</span></div></div></blockquot=
e><div><br>Specifying order of evaluation does not make it a lot harder to =
implement faster programs.<br>Specifying order of evaluation increases expr=
essiveness because it makes programs legal that are now illegal.<br>The com=
bination of confidence and ignorance accrues to those people who insist tha=
t the evil consequences of failing to specify order of evaluation can be mi=
tigated by exhortation and review.<br>Specifying order of evaluation does n=
ot take away anyone&#39;s freedom.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY5u10X55Ujs5cMxPGwoFZJMmW%2BLH=
LwztZ4fA-zQ3Sxjw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY5u10X55=
Ujs5cMxPGwoFZJMmW%2BLHLwztZ4fA-zQ3Sxjw%40mail.gmail.com</a>.<br />

--001a1143f1541c5b84052da3f09c--

.

On 2016-03-09 15:56, Hyman Rosen wrote:
> Specifying order of evaluation does not make it a lot harder to implement
> faster programs.

It does, at least to the extent that it is now much harder to ever get
reordering / CSE optimizations. Somewhat harder for the compiler (in the
now-exceedingly-rare cases where it is possible *at all*), but much
harder for users (who must newly annotate all their code), and hard from
a standard perspective because *we DON'T HAVE* the necessary annotations.

> Specifying order of evaluation increases expressiveness because it makes
> programs legal that are now illegal.

Uh... what? It *might* cause programs that are incorrect due to wrong
expectations about unspecified behavior to become correct. It might also
do the opposite. In no way, however, are such programs "illegal".

> Specifying order of evaluation does not take away anyone's freedom.

Uh... compiler's freedom? Seriously, how can you say that with a
straight face?

Removing unspecified behavior *by definition* reduces compiler freedom.

You may have a valid point in there, somewhere, but it's hiding behind
some really poor phrasing...

--
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/nbqaj3%24t7t%241%40ger.gmane.org.

.

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

On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2016-03-09 15:56, Hyman Rosen wrote:
> > Specifying order of evaluation increases expressiveness because it makes
> > programs legal that are now illegal.
>
> Uh... what? It *might* cause programs that are incorrect due to wrong
> expectations about unspecified behavior to become correct. It might also
> do the opposite. In no way, however, are such programs "illegal".
>

What is the opposite? The order today is unspecified. There cannot be _any_
expectations by definition. Any code that even remotely relies on such
expectation is already broken. Specifying an order will only make it fail
consistently *every single time*! Why is this so hard to get across?


>
> > Specifying order of evaluation does not take away anyone's freedom.
>
> Uh... compiler's freedom? Seriously, how can you say that with a
> straight face?
>
> Removing unspecified behavior *by definition* reduces compiler freedom.
>

What is the compiler doing with this alleged freedom **today**? Can you
show me an example of where specifying an order will take away that 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/CALEPxfti9TV%2B%2BFb0cJFA7eAdnMjYvQUgAp%3DR13twgv6g3U14_Q%40mail.gmail.com.

--001a11c3735c78c271052da69a70
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, Mar 9, 2016 at 6:11 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2016-=
03-09 15:56, Hyman Rosen wrote:<br>
</span><span>&gt; Specifying order of evaluation increases expressiveness b=
ecause it makes<br>
&gt; programs legal that are now illegal.<br>
<br>
</span>Uh... what? It *might* cause programs that are incorrect due to wron=
g<br>
expectations about unspecified behavior to become correct. It might also<br=
>
do the opposite. In no way, however, are such programs &quot;illegal&quot;.=
<br></blockquote><div><br></div><div>What is the opposite?=C2=A0The order t=
oday is unspecified. There cannot be=C2=A0_any_ expectations by definition.=
 Any code that even remotely=C2=A0relies on such expectation=C2=A0is alread=
y broken.=C2=A0Specifying an order will only make it fail consistently *eve=
ry single time*! Why is this so hard to get across?=C2=A0</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">
<span><br>
&gt; Specifying order of evaluation does not take away anyone&#39;s freedom=
..<br>
<br>
</span>Uh... compiler&#39;s freedom? Seriously, how can you say that with a=
<br>
straight face?<br>
<br>
Removing unspecified behavior *by definition* reduces compiler freedom.<br>=
</blockquote><div><br></div><div>What is=C2=A0the compiler doing with this =
alleged freedom **today**? Can you show me an example of where specifying a=
n order will take away that freedom?</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxfti9TV%2B%2BFb0cJFA7eAdnMjYvQUg=
Ap%3DR13twgv6g3U14_Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfti9T=
V%2B%2BFb0cJFA7eAdnMjYvQUgAp%3DR13twgv6g3U14_Q%40mail.gmail.com</a>.<br />

--001a11c3735c78c271052da69a70--

.

------=_Part_168_306634536.1457585907574
Content-Type: multipart/alternative;
 boundary="----=_Part_169_798549894.1457585907575"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8A=E5=8D=884:56:58=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Mar 9, 2016 at 11:31 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8A=E5=8D=8812:33:07=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>
> A computer program is the means whereby a computer is instructed to carry=
=20
> out a computation.  Allowing the meaning of parts of a program to be=20
> unspecified is a failure to provide specific instructions to the computer=
,=20
> and to the extent that the author of the program did not mean this lack o=
f=20
> specificity, is a trap for the author and for all future users of the=20
> program.
>
> I'm strongly against at this point. We were talking programs which are no=
t=20
> necessarily implemented by computation in machines. A specification of a=
=20
> general-purposed language should be able to describe programs actually no=
t=20
> physically implementable, e.g. a program never terminate. Otherwise you=
=20
> should eliminate all undefined behavior at first.
>
>
> Why would you want such a thing?  Or rather, why would you want such a=20
> thing in the context of a programming language that is intended for writi=
ng=20
> programs that are executed?  There are plenty of pidgin languages that=20
> authors of computer science papers use to write pseudocode.  C++ isn't on=
e=20
> of them.  And what is wrong with a program that never terminates?  Many=
=20
> servers are written like that, for example.
>
> =20
>
The reason is simple: to be simple. The rules of the language is not built=
=20
based on any concrete machines. It is the "abstract machine". Programs=20
running on physical machine is the implementation detail, which is far more=
=20
complicated and not suitable for the language specification.

There is nothing wrong with a program that never terminates. But it is=20
wrong to guarantee a program run forever on any computer in reality,=20
because you are not able to, and you should not waste time in such a=20
strange way. That's the difference. You have also been actually talking=20
about the program without machines at first. Good.

When a program is not running on a computer, it is still available for your=
=20
brain. Though your brain is not a conforming implementation, it is still=20
valuable to "run": to analysis the program, or more specifically, to verify=
=20
the language specification plus the program, manually, which is frequently=
=20
occurred for source of high level languages. There are properties which are=
=20
totally irrelevant to computers, e.g. the deliberated intention to=20
specifying nondeterminism. On the other hand, if you insist only properties=
=20
to machine is important, it can be arguable why static types are need: that=
=20
type information would have been dropped when the computer run the=20
translated program.
=20

> Note, it is the semantics of parts of programs is guaranteed to be=20
> "unspecified", as well as some predictable behavior. Language rules can n=
ot=20
> specify the actually meaning of programs totally. The latter depends on=
=20
> your intent and use.
>
>
> How can a program running on a computer possibly discern my intent?  I=20
> express my intent by writing the program.  To the extent that the=20
> programming language allows me to write apparent but non-obligatory inten=
t,=20
> it is creating a trap that will lead me to write programs that do not do=
=20
> what I want them to do, and worse, programs that appear to do what I want=
=20
> them to do now, but arbitrarily change their behavior sometime in the=20
> future.
>
> Creating a trap is far better than *being disabled*. You actually *can *d=
o=20
what you expected currently. It just not in a style of your favor, requires=
=20
separated statements rather than within subexpressions.
=20

> I cannot fathom why anyone would want such a thing, but I accept that=20
> there are people who do.  Those people must be fought, for the good of th=
e=20
> community.
>
> I am somewhat surprising so easy to remove expressiveness in the language=
=20
with no other undoubtful gain. Why insisting on such a problematic hack?=20
What is the point to change the rules silently for machines but noisy for=
=20
humans? =20

>
> And this for the dubious prospect that the program may sometimes run a=20
> little faster, and for the dubious pleasure of mocking the author for=20
> failing to notice the problem.  There is nothing bad or ugly about relyin=
g=20
> on order of evaluation.  The badness and ugliness is in taking an error i=
n=20
> programming language design and elevating that error into a principle.
>
> If a design makes it always a lot harder to implement faster programs and=
=20
> brings nothing more about expressiveness or abstraction, that design is=
=20
> problematic. There is nothing bad or ugly relying on order of evaluation=
=20
> *intentionally*, but it is absolutely bad to blur the situation of being=
=20
> confident and ignorant, also definitely ugly to encourage innocent users =
t
>
> ...

--=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/3257959f-b546-40aa-a921-e39169423a6e%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=884:56:58=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>On Wed, Mar 9, 2016 at 11:31 AM, FrankHB1989 <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"ut5bvI6tBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">frank...@gmail.com</a>&gt;</span> wrote:<br><blockquote style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 U=
TC+8=E4=B8=8A=E5=8D=8812:33:07=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A<span><blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">A computer program is the means=
 whereby a computer is instructed to carry out a computation.=C2=A0 Allowin=
g the meaning of parts of a program to be unspecified is a failure to provi=
de specific instructions to the computer, and to the extent that the author=
 of the program did not mean this lack of specificity, is a trap for the au=
thor and for all future users of the program.<div><br></div></div></blockqu=
ote></span><div>I&#39;m strongly against at this point. We were talking pro=
grams which are not necessarily implemented by computation in machines. A s=
pecification of a general-purposed language should be able to describe prog=
rams actually not physically implementable, e.g. a program never terminate.=
 Otherwise you should eliminate all undefined behavior at first.<br></div><=
/div></blockquote><div><br>Why would you want such a thing?=C2=A0 Or rather=
, why would you want such a thing in the context of a programming language =
that is intended for writing programs that are executed?=C2=A0 There are pl=
enty of pidgin languages that authors of computer science papers use to wri=
te pseudocode.=C2=A0 C++ isn&#39;t one of them.=C2=A0 And what is wrong wit=
h a program that never terminates?=C2=A0 Many servers are written like that=
, for example.<br><br>=C2=A0</div></div></div></div></blockquote><div>The r=
eason is simple: to be simple. The rules of the language is not built based=
 on any concrete machines. It is the &quot;abstract machine&quot;. Programs=
 running on physical machine is the implementation detail, which is far mor=
e complicated and not suitable for the language specification.<br><br>There=
 is nothing wrong with a program that never terminates. But it is wrong to =
guarantee a program run forever on any computer in reality, because you are=
 not able to, and you should not waste time in such a strange way. That&#39=
;s the difference. You have also been actually talking about the program wi=
thout machines at first. Good.<br><br>When a program is not running on a co=
mputer, it is still available for your brain. Though your brain is not a co=
nforming implementation, it is still valuable to &quot;run&quot;: to analys=
is the program, or more specifically, to verify the language specification =
plus the program, manually, which is frequently occurred for source of high=
 level languages. There are properties which are totally irrelevant to comp=
uters, e.g. the deliberated intention to specifying nondeterminism. On the =
other hand, if you insist only properties to machine is important, it can b=
e arguable why static types are need: that type information would have been=
 dropped when the computer run the translated program.<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><blo=
ckquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div>Note, it is the semantics of parts of programs i=
s guaranteed to be &quot;unspecified&quot;, as well as some predictable beh=
avior. Language rules can not specify the actually meaning of programs tota=
lly. The latter depends on your intent and use.<br></div></div></blockquote=
><div><br>How can a program running on a computer possibly discern my inten=
t?=C2=A0 I express my intent by writing the program.=C2=A0 To the extent th=
at the programming language allows me to write apparent but non-obligatory =
intent, it is creating a trap that will lead me to write programs that do n=
ot do what I want them to do, and worse, programs that appear to do what I =
want them to do now, but arbitrarily change their behavior sometime in the =
future.<br><br></div></div></div></div></blockquote><div>Creating a trap is=
 far better than <i>being disabled</i>. You actually <i>can </i>do what you=
 expected currently. It just not in a style of your favor, requires separat=
ed statements rather than within subexpressions.<br>=C2=A0<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><div>I can=
not fathom why anyone would want such a thing, but I accept that there are =
people who do.=C2=A0 Those people must be fought, for the good of the commu=
nity.<br><br></div></div></div></div></blockquote><div>I am somewhat surpri=
sing so easy to remove expressiveness in the language with no other undoubt=
ful gain. Why insisting on such a problematic hack? What is the point to ch=
ange the rules silently for machines but noisy for humans?=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><di=
v><br></div><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><span><blockquote style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div></div><div>And this for the dubious prospect that the program may =
sometimes run a little faster, and for the dubious pleasure of mocking the =
author for failing to notice the problem.=C2=A0 There is nothing bad or ugl=
y about relying on order of evaluation.=C2=A0 The badness and ugliness is i=
n taking an error in programming language design and elevating that error i=
nto a principle.</div></div><div><br></div></blockquote></span><div>If a de=
sign makes it always a lot harder to implement faster programs and brings n=
othing more about expressiveness or abstraction, that design is <span>probl=
ematic</span>. There is nothing bad or ugly relying on order of evaluation =
<i>intentionally</i>, but it is absolutely bad to blur <span>the situation =
of being confident and ignorant, also </span><span><span>definitely </span>=
ugly to encourage innocent users t</span></div></div></blockquote></div></d=
iv></div>...</blockquote></div>

<p></p>

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

------=_Part_169_798549894.1457585907575--
------=_Part_168_306634536.1457585907574--

.

------=_Part_157_1249513823.1457587401785
Content-Type: multipart/alternative;
 boundary="----=_Part_158_1264961103.1457587401785"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8B=E5=8D=8811:07:36=EF=BC=8CMatthew Woehlke=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On 2016-03-08 18:06, Brent Friedman wrote:=20
> > We have some code which uses a style like this for declaring UI=20
> elements:=20
> >=20
> > new Window().add(=20
> >    new BorderElement(3_px).add(=20
> >       new Scroller().add( new TextBox("Hello"), new Image("chat.png")=
=20
>  ),=20
> >       new Hyperlink("help.html")=20
> >     ) );=20
> >=20
> > Though the syntax is handy, you can imagine that expressions like this=
=20
> are=20
> > really dangerous for any side-effects they might have.=20
>
> Or... don't introduce side effects in widget creation. There should be=20
> no reason I can't get the same effect by writing:=20
>
>   auto const window =3D new Window();=20
>   auto const image =3D new Image("chat.png");=20
>   auto const text =3D new TextBox("Hello");=20
>   auto const link =3D new Hyperlink("help.html");=20
>   auto const scroll =3D new Scroller();=20
>   auto const border =3D new BorderElement(3_px);=20
>
>   border.add(scroll);=20
>   scroll.add(text, image, link);=20
>   window.add(border);=20
>
> If that, or any other ordering, results in modified semantics, then IMHO=
=20
> your API leaves something to be desired...=20
> ...

I don't want side effect embedded in hard-coded widget creation, because it=
=20
is relatively inexpressive and error-prone.
However, I also don't like direct creation of objects. That kind of=20
creation as low-level primitives may be acceptable (though I still don't=20
like to force users reference the widget by limited and intrusive=20
indirection mechanism such as passing values of widget pointers), but not=
=20
good enough for general use. The keyword 'new' makes it worse.=20
I wish someday I can have some APIs to convert the widget layout (in both=
=20
embedded DSLs implemented by something like user-defined literals and=20
external source like S-expr/XML/JSON) directly to the expected result, as=
=20
efficient as possible (even all constexpr'd when possible). Leave side=20
effect here may lead to amazing consequences.




=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/5e6100cc-92dc-4d89-977a-8627800164e9%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=889=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=8811:07:36=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-03-08 18:06, Brent Friedman wrote:
<br>&gt; We have some code which uses a style like this for declaring UI el=
ements:
<br>&gt;=20
<br>&gt; new Window().add(
<br>&gt; =C2=A0 =C2=A0new BorderElement(3_px).add(
<br>&gt; =C2=A0 =C2=A0 =C2=A0 new Scroller().add( new TextBox(&quot;Hello&q=
uot;), new Image(&quot;chat.png&quot;) =C2=A0),
<br>&gt; =C2=A0 =C2=A0 =C2=A0 new Hyperlink(&quot;help.html&quot;)
<br>&gt; =C2=A0 =C2=A0 ) );
<br>&gt;=20
<br>&gt; Though the syntax is handy, you can imagine that expressions like =
this are
<br>&gt; really dangerous for any side-effects they might have.
<br>
<br>Or... don&#39;t introduce side effects in widget creation. There should=
 be
<br>no reason I can&#39;t get the same effect by writing:
<br>
<br>=C2=A0 auto const window =3D new Window();
<br>=C2=A0 auto const image =3D new Image(&quot;chat.png&quot;);
<br>=C2=A0 auto const text =3D new TextBox(&quot;Hello&quot;);
<br>=C2=A0 auto const link =3D new Hyperlink(&quot;help.html&quot;);
<br>=C2=A0 auto const scroll =3D new Scroller();
<br>=C2=A0 auto const border =3D new BorderElement(3_px);
<br>
<br>=C2=A0 border.add(scroll);
<br>=C2=A0 scroll.add(text, image, link);
<br>=C2=A0 window.add(border);
<br>
<br>If that, or any other ordering, results in modified semantics, then IMH=
O
<br>your API leaves something to be desired...
<br>
....</blockquote><div>I don&#39;t want side effect embedded in hard-coded wi=
dget creation, because it is relatively inexpressive and error-prone.<br>Ho=
wever, I also don&#39;t like direct creation of objects. That kind of creat=
ion as low-level primitives may be acceptable (though I still don&#39;t lik=
e to force users reference the widget by limited and intrusive indirection =
mechanism such as passing values of widget pointers), but not good enough f=
or general use. The keyword &#39;new&#39; makes it worse. <br>I wish someda=
y I can have some APIs to convert the widget layout (in both embedded DSLs =
implemented by something like user-defined literals and external source lik=
e S-expr/XML/JSON) directly to the expected result, as efficient as possibl=
e (even all constexpr&#39;d when possible). Leave side effect here may lead=
 to amazing consequences.<br><br><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5e6100cc-92dc-4d89-977a-8627800164e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e6100cc-92dc-4d89-977a-8627800164e9=
%40isocpp.org</a>.<br />

------=_Part_158_1264961103.1457587401785--
------=_Part_157_1249513823.1457587401785--

.

------=_Part_178_378474036.1457589884481
Content-Type: multipart/alternative;
 boundary="----=_Part_179_417735382.1457589884482"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8A=E5=8D=884:56:58=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A

>
> And this for the dubious prospect that the program may sometimes run a=20
>>> little faster, and for the dubious pleasure of mocking the author for=
=20
>>> failing to notice the problem.  There is nothing bad or ugly about rely=
ing=20
>>> on order of evaluation.  The badness and ugliness is in taking an error=
 in=20
>>> programming language design and elevating that error into a principle.
>>>
>>> If a design makes it always a lot harder to implement faster programs=
=20
>> and brings nothing more about expressiveness or abstraction, that design=
 is=20
>> problematic. There is nothing bad or ugly relying on order of evaluation=
=20
>> *intentionally*, but it is absolutely bad to blur the situation of being=
=20
>> confident and ignorant, also definitely ugly to encourage innocent users=
=20
>> to do so by specification which takes away freedom of some others.
>>
>
> Specifying order of evaluation does not make it a lot harder to implement=
=20
> faster programs.
>

Can you illustrate some ways to guarantee the implementations only using=20
as-if rules behave as efficient as any possible implementations with aid of=
=20
unsequenced evaluation rules?

Specifying order of evaluation increases expressiveness because it makes=20
> programs legal that are now illegal.
>

It does not make programs illegal because every weill-formed and=20
well-defined programs will still be the same. Only already broken programs=
=20
are effected. To expose such programs has nothing to do with being legal or=
=20
not. Current implementations are allowed to do such things.

On the contrast, it decreases expressiveness *of the language* because it=
=20
makes the allowed set of properties of the source program strictly less=20
than before.
=20

> The combination of confidence and ignorance accrues to those people who=
=20
> insist that the evil consequences of failing to specify order of evaluati=
on=20
> can be mitigated by exhortation and review.
> Specifying order of evaluation does not take away anyone's freedom.
>
=20
Specifying order has taken away the freedom about assuming well-defined and=
=20
safe reordering based on unsequenced evaluations, which including=20
refactoring currently correct code without inspecting the whole=20
implementation details of subexpressions for humans, and optimizing without=
=20
relying on the as-if rule for compilers.
=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/06d04060-ed8b-4eca-a5a8-16b340b48bb6%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=884:56:58=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<br><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: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:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div></div><div>And this for the dubious prospect th=
at the program may sometimes run a little faster, and for the dubious pleas=
ure of mocking the author for failing to notice the problem.=C2=A0 There is=
 nothing bad or ugly about relying on order of evaluation.=C2=A0 The badnes=
s and ugliness is in taking an error in programming language design and ele=
vating that error into a principle.</div></div><div><br></div></blockquote>=
</span><div>If a design makes it always a lot harder to implement faster pr=
ograms and brings nothing more about expressiveness or abstraction, that de=
sign is <span>problematic</span>. There is nothing bad or ugly relying on o=
rder of evaluation <i>intentionally</i>, but it is absolutely bad to blur <=
span>the situation of being confident and ignorant, also </span><span><span=
>definitely </span>ugly to encourage innocent users to do so by specificati=
on which takes away freedom of some others.</span></div></div></blockquote>=
<div><br>Specifying order of evaluation does not make it a lot harder to im=
plement faster programs.<br></div></div></div></div></blockquote><div><br>C=
an you illustrate some ways to guarantee the implementations only using as-=
if rules behave as efficient as any possible implementations with aid of un=
sequenced evaluation rules?<br><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><div class=3D"gmail_quote"><div>Specifying=
 order of evaluation increases expressiveness because it makes programs leg=
al that are now illegal.<br></div></div></div></div></blockquote><div><br>I=
t does not make programs illegal because every weill-formed and well-define=
d programs will still be the same. Only already broken programs are effecte=
d. To expose such programs has nothing to do with being legal or not. Curre=
nt implementations are allowed to do such things.<br><br>On the contrast, i=
t decreases expressiveness <i>of the language</i> because it makes the allo=
wed set of properties of the source program strictly less than before.<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>The combination of confidence and i=
gnorance accrues to those people who insist that the evil consequences of f=
ailing to specify order of evaluation can be mitigated by exhortation and r=
eview.<br>Specifying order of evaluation does not take away anyone&#39;s fr=
eedom.</div></div></div></div></blockquote><div>=C2=A0</div><div>Specifying=
 order has taken away the freedom about assuming well-defined and safe reor=
dering based on unsequenced evaluations, which including refactoring curren=
tly correct code without inspecting the whole implementation details of sub=
expressions for humans, and optimizing without relying on the as-if rule fo=
r compilers.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/06d04060-ed8b-4eca-a5a8-16b340b48bb6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/06d04060-ed8b-4eca-a5a8-16b340b48bb6=
%40isocpp.org</a>.<br />

------=_Part_179_417735382.1457589884482--
------=_Part_178_378474036.1457589884481--

.

------=_Part_196_1880148759.1457589946609
Content-Type: multipart/alternative;
 boundary="----=_Part_197_1588191883.1457589946610"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8A=E5=8D=888:07:46=EF=BC=8CDilip Ranganathan=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke <mwoehlk...@gmail.com=20
> <javascript:>> wrote:
>
> On 2016-03-09 15:56, Hyman Rosen wrote:
> > Specifying order of evaluation increases expressiveness because it make=
s
> > programs legal that are now illegal.
>
> Uh... what? It *might* cause programs that are incorrect due to wrong
> expectations about unspecified behavior to become correct. It might also
> do the opposite. In no way, however, are such programs "illegal".
>
>
> What is the opposite? The order today is unspecified. There cannot=20
> be _any_ expectations by definition. Any code that even remotely relies o=
n=20
> such expectation is already broken. Specifying an order will only make it=
=20
> fail consistently *every single time*! Why is this so hard to get across?=
=20
>
You can at least expect reordering any of these unspecified evaluated=20
operands would be safe when the code is correct. The compilers can also=20
expect this so it can optimize without (difficult) proving work to obey the=
=20
as-if rule.=20

> =20
>
>
> > Specifying order of evaluation does not take away anyone's freedom.
>
> Uh... compiler's freedom? Seriously, how can you say that with a
> straight face?
>
> Removing unspecified behavior *by defini
>
> ...

--=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/9e593fe3-1130-4c74-9901-a7b71c816cb6%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=888:07:46=EF=BC=8CDilip Ranganat=
han=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"><div><div>On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"M67lNfi3BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">mwoehlk...@gmail.com</a>&gt;</span> wrote:<br><blockquote =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><sp=
an>On 2016-03-09 15:56, Hyman Rosen wrote:<br>
</span><span>&gt; Specifying order of evaluation increases expressiveness b=
ecause it makes<br>
&gt; programs legal that are now illegal.<br>
<br>
</span>Uh... what? It *might* cause programs that are incorrect due to wron=
g<br>
expectations about unspecified behavior to become correct. It might also<br=
>
do the opposite. In no way, however, are such programs &quot;illegal&quot;.=
<br></blockquote><div><br></div><div>What is the opposite?=C2=A0The order t=
oday is unspecified. There cannot be=C2=A0_any_ expectations by definition.=
 Any code that even remotely=C2=A0relies on such expectation=C2=A0is alread=
y broken.=C2=A0Specifying an order will only make it fail consistently *eve=
ry single time*! Why is this so hard to get across?=C2=A0</div></div></div>=
</div></blockquote><div>You can at least expect reordering any of these uns=
pecified evaluated operands would be safe when the code is correct. The com=
pilers can also expect this so it can optimize without (difficult) proving =
work to obey the as-if rule. <br></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><div>=C2=A0</div><blockquote style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
&gt; Specifying order of evaluation does not take away anyone&#39;s freedom=
..<br>
<br>
</span>Uh... compiler&#39;s freedom? Seriously, how can you say that with a=
<br>
straight face?<br>
<br>
Removing unspecified behavior *by defini</blockquote></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9e593fe3-1130-4c74-9901-a7b71c816cb6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9e593fe3-1130-4c74-9901-a7b71c816cb6=
%40isocpp.org</a>.<br />

------=_Part_197_1588191883.1457589946610--
------=_Part_196_1880148759.1457589946609--

.

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

On 10 Mar 2016 00:07, "Dilip Ranganathan" <misc.usage@gmail.com> wrote:
>
> On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
>>
>> On 2016-03-09 15:56, Hyman Rosen wrote:
>> > Specifying order of evaluation increases expressiveness because it
makes
>> > programs legal that are now illegal.
>>
>> Uh... what? It *might* cause programs that are incorrect due to wrong
>> expectations about unspecified behavior to become correct. It might also
>> do the opposite. In no way, however, are such programs "illegal".
>
>
> What is the opposite? The order today is unspecified. There cannot
be _any_ expectations by definition. Any code that even remotely relies on
such expectation is already broken. Specifying an order will only make it
fail consistently *every single time*! Why is this so hard to get across?
>

You can ask your vendor for an assurance that they will honor your
expectation, and right now they can provide such an assurance. This can be
explicit or a more general commitment to backward compatibility, or just an
assurance that no major changes to program translation will occur. Under a
specified order the vendor may be forced to repudiate that assurance.

Implementations are not required to document unspecified behavior, but
there is nothing to prevent them from doing so if they wish.

--
You received this message because you are 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/CAJnLdObEp-oaJ3hPw-LpxZEa-VUg6XrmJ7re9hS9Nq2cN%2BV82Q%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 10 Mar 2016 00:07, &quot;Dilip Ranganathan&quot; &lt;<a href=3D"mailto:m=
isc.usage@gmail.com">misc.usage@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke &lt;<a href=3D"mailto:=
mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 2016-03-09 15:56, Hyman Rosen wrote:<br>
&gt;&gt; &gt; Specifying order of evaluation increases expressiveness becau=
se it makes<br>
&gt;&gt; &gt; programs legal that are now illegal.<br>
&gt;&gt;<br>
&gt;&gt; Uh... what? It *might* cause programs that are incorrect due to wr=
ong<br>
&gt;&gt; expectations about unspecified behavior to become correct. It migh=
t also<br>
&gt;&gt; do the opposite. In no way, however, are such programs &quot;illeg=
al&quot;.<br>
&gt;<br>
&gt;<br>
&gt; What is the opposite?=C2=A0The order today is unspecified. There canno=
t be=C2=A0_any_ expectations by definition. Any code that even remotely=C2=
=A0relies on such expectation=C2=A0is already broken.=C2=A0Specifying an or=
der will only make it fail consistently *every single time*! Why is this so=
 hard to get across?=C2=A0<br>
&gt; =C2=A0</p>
<p dir=3D"ltr">You can ask your vendor for an assurance that they will hono=
r your expectation, and right now they can provide such an assurance. This =
can be explicit or a more general commitment to backward compatibility, or =
just an assurance that no major changes to program translation will occur. =
Under a specified order the vendor may be forced to repudiate that assuranc=
e. </p>
<p dir=3D"ltr">Implementations are not required to document unspecified beh=
avior, but there is nothing to prevent them from doing so if they wish. </p=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObEp-oaJ3hPw-LpxZEa-VUg6XrmJ7re=
9hS9Nq2cN%2BV82Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObEp-oaJ3=
hPw-LpxZEa-VUg6XrmJ7re9hS9Nq2cN%2BV82Q%40mail.gmail.com</a>.<br />

--001a1140f750560882052dac01da--

.

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

I see to main excuses for rejecting a proper evaluation ordering in the
whole discussion:
1. projection of shortcomings of compiler designers minority over the
majority of programmers( many of whom running from C++ for good reasons).
2.Conflicts with optimization.

Am I missing anything? here are my replies for those allebies:
1. Aren't tools the result of man's attempt to make hard tasks easier? Why
should one believe that writing efficient code must be hard and reading and
maintaining it even harder?
2. What on earth does optimization have to do with ordering? The golden
rule of optimization is to enhance overheads while keeping side effects
consistent. regardless of ordering, optimization techniques such as CSE can
be applied in contexts where common subexpression doesn't have any
side-effects.OOE can be applied when side-effects of code sequences are
proven to be uncorrelated...

I don't care if a specific implementation uses AST or not; What matters to
me is that the best and most naturally expected order of evaluation is that
of precedence and associativity. What I am asking for, is a strong reason
for rejecting a well-organized ordering scheme. I am really curious to know
why I should not expect the following line:

cout << (x=0) << "," << ++x << endl;

produce:

0,1

regards,
FM.


2016-03-10 10:04 GMT+03:30 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org>:

>
> On 10 Mar 2016 00:07, "Dilip Ranganathan" <misc.usage@gmail.com> wrote:
> >
> > On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke <
> mwoehlke.floss@gmail.com> wrote:
> >>
> >> On 2016-03-09 15:56, Hyman Rosen wrote:
> >> > Specifying order of evaluation increases expressiveness because it
> makes
> >> > programs legal that are now illegal.
> >>
> >> Uh... what? It *might* cause programs that are incorrect due to wrong
> >> expectations about unspecified behavior to become correct. It might also
> >> do the opposite. In no way, however, are such programs "illegal".
> >
> >
> > What is the opposite? The order today is unspecified. There cannot
> be _any_ expectations by definition. Any code that even remotely relies on
> such expectation is already broken. Specifying an order will only make it
> fail consistently *every single time*! Why is this so hard to get across?
> >
>
> You can ask your vendor for an assurance that they will honor your
> expectation, and right now they can provide such an assurance. This can be
> explicit or a more general commitment to backward compatibility, or just an
> assurance that no major changes to program translation will occur. Under a
> specified order the vendor may be forced to repudiate that assurance.
>
> Implementations are not required to document unspecified behavior, but
> there is nothing to prevent them from doing so if they wish.
>
> --
> You received this message because you are 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/CAJnLdObEp-oaJ3hPw-LpxZEa-VUg6XrmJ7re9hS9Nq2cN%2BV82Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObEp-oaJ3hPw-LpxZEa-VUg6XrmJ7re9hS9Nq2cN%2BV82Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>



--
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my 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/CALDL7dF0Vz-SYhAric9XhW%3Dw9jPjWmgy90EzXR%2BXgJnOgOf-fA%40mail.gmail.com.

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

<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:&#39;ari=
al narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">I see to main excuse=
s for rejecting a proper evaluation ordering in the whole discussion:</div>=
<div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sa=
ns-serif;font-size:large" dir=3D"ltr">1. projection of shortcomings of comp=
iler designers minority over the majority of programmers( many of whom runn=
ing from C++ for good reasons).</div><div class=3D"gmail_default" style=3D"=
font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">=
2.Conflicts with optimization.</div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><=
br></div><div class=3D"gmail_default" style=3D"font-family:&#39;arial narro=
w&#39;,sans-serif;font-size:large" dir=3D"ltr">Am I missing anything? here =
are my replies for those allebies:</div><div class=3D"gmail_default" style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"l=
tr">1. Aren&#39;t tools the result of man&#39;s attempt to make hard tasks =
easier? Why should one believe that writing efficient code must be hard and=
 reading and maintaining it even harder?=C2=A0</div><div class=3D"gmail_def=
ault" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:larg=
e" dir=3D"ltr">2. What on earth does optimization have to do with ordering?=
 The golden rule of optimization is to enhance overheads while keeping side=
 effects consistent. regardless of ordering, optimization techniques such a=
s CSE can be applied in contexts where common subexpression doesn&#39;t hav=
e any side-effects.OOE can be applied when side-effects of code sequences a=
re proven to be uncorrelated...</div><div class=3D"gmail_default" style=3D"=
font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">=
<br></div><div class=3D"gmail_default" style=3D"font-family:&#39;arial narr=
ow&#39;,sans-serif;font-size:large" dir=3D"ltr">I don&#39;t care if a speci=
fic implementation uses AST or not; What matters to me is that the best and=
 most naturally expected order of evaluation is that of precedence and asso=
ciativity. What I am asking for, is a strong reason for rejecting a well-or=
ganized ordering scheme. I am really curious to know why I should not expec=
t the following line:</div><div class=3D"gmail_default" style=3D"font-famil=
y:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div>=
<div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sa=
ns-serif;font-size:large" dir=3D"ltr">cout &lt;&lt; (x=3D0) &lt;&lt; &quot;=
,&quot; &lt;&lt; ++x &lt;&lt; endl;</div><div class=3D"gmail_default" style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"l=
tr"><br></div><div class=3D"gmail_default" style=3D"font-family:&#39;arial =
narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">produce:</div><div clas=
s=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;=
font-size:large" dir=3D"ltr"><br></div><div class=3D"gmail_default" style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"l=
tr">0,1</div><div class=3D"gmail_default" style=3D"font-family:&#39;arial n=
arrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div class=3D"=
gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large" dir=3D"ltr">regards,</div><div class=3D"gmail_default" style=3D=
"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"=
>FM.</div><div class=3D"gmail_default" style=3D"font-family:&#39;arial narr=
ow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><div dir=3D"ltr">2016-03-10=
 10:04 GMT+03:30 &#39;Edward Catmur&#39; via ISO C++ Standard - Future Prop=
osals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" tar=
get=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>:</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><span class=3D""><p dir=3D"ltr"><br>
On 10 Mar 2016 00:07, &quot;Dilip Ranganathan&quot; &lt;<a href=3D"mailto:m=
isc.usage@gmail.com" target=3D"_blank">misc.usage@gmail.com</a>&gt; wrote:<=
br>
&gt;<br>
&gt; On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke &lt;<a href=3D"mailto:=
mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt=
; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 2016-03-09 15:56, Hyman Rosen wrote:<br>
&gt;&gt; &gt; Specifying order of evaluation increases expressiveness becau=
se it makes<br>
&gt;&gt; &gt; programs legal that are now illegal.<br>
&gt;&gt;<br>
&gt;&gt; Uh... what? It *might* cause programs that are incorrect due to wr=
ong<br>
&gt;&gt; expectations about unspecified behavior to become correct. It migh=
t also<br>
&gt;&gt; do the opposite. In no way, however, are such programs &quot;illeg=
al&quot;.<br>
&gt;<br>
&gt;<br>
&gt; What is the opposite?=C2=A0The order today is unspecified. There canno=
t be=C2=A0_any_ expectations by definition. Any code that even remotely=C2=
=A0relies on such expectation=C2=A0is already broken.=C2=A0Specifying an or=
der will only make it fail consistently *every single time*! Why is this so=
 hard to get across?=C2=A0<br>
&gt; =C2=A0</p>
</span><p dir=3D"ltr">You can ask your vendor for an assurance that they wi=
ll honor your expectation, and right now they can provide such an assurance=
.. This can be explicit or a more general commitment to backward compatibili=
ty, or just an assurance that no major changes to program translation will =
occur. Under a specified order the vendor may be forced to repudiate that a=
ssurance. </p>
<p dir=3D"ltr">Implementations are not required to document unspecified beh=
avior, but there is nothing to prevent them from doing so if they wish. </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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAJnLdObEp-oaJ3hPw-LpxZEa-VUg6XrmJ7re=
9hS9Nq2cN%2BV82Q%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAJnLdObEp-oaJ3hPw-LpxZEa-VUg6XrmJ7re9hS9Nq2cN%2BV82Q%40mail.gmail.c=
om</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how am I suppos=
ed to end the twisted road of=C2=A0 your hair in such a dark night??<br>unl=
ess the candle of your face does shed some light upon my way!!!<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dF0Vz-SYhAric9XhW%3Dw9jPjWmgy90=
EzXR%2BXgJnOgOf-fA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dF0Vz-S=
YhAric9XhW%3Dw9jPjWmgy90EzXR%2BXgJnOgOf-fA%40mail.gmail.com</a>.<br />

--001a113a66846acbfe052dade08e--

.

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

On Thu, Mar 10, 2016 at 8:47 AM, Farid Mehrabi <farid.mehrabi@gmail.com>
wrote:

> I see to main excuses for rejecting a proper evaluation ordering in the
> whole discussion:
> 1. projection of shortcomings of compiler designers minority over the
> majority of programmers( many of whom running from C++ for good reasons).
>

I don't understand this point. What "shortcomings" are you referring to?


> 2.Conflicts with optimization.
>
> Am I missing anything?
>

Yes, as has been discussed ad nauseam already: expressiveness,
maintainability, backwards compatibility.


> here are my replies for those allebies:
> 1. Aren't tools the result of man's attempt to make hard tasks easier? Why
> should one believe that writing efficient code must be hard and reading and
> maintaining it even harder?
>

Exactly, which is why the current rules should be kept; a defined order of
evaluation would make reading code more involved, maintaining it
significantly more complex and writing efficient code all but impossible.


> 2. What on earth does optimization have to do with ordering? The golden
> rule of optimization is to enhance overheads while keeping side effects
> consistent. regardless of ordering, optimization techniques such as CSE can
> be applied in contexts where common subexpression doesn't have any
> side-effects.OOE can be applied when side-effects of code sequences are
> proven to be uncorrelated...
>

Free order of evaluation is the most natural way for the programmer to
communicate to the implementation that side effects are absent or can be
assumed to be uncorrelated; this means that there is no need for the
compiler to prove anything, which may be difficult or impossible in the
general case. In the (limited) instances where the programmer desires a
specific ordering of side effects, the language already provides (multiple)
ways to explicitly order evaluation.


> I don't care if a specific implementation uses AST or not; What matters to
> me is that the best and most naturally expected order of evaluation is that
> of precedence and associativity.
>

If we had to pick a single order of evaluation, that would be the natural
one. Fortunately, there is no need to do so.


> What I am asking for, is a strong reason for rejecting a well-organized
> ordering scheme. I am really curious to know why I should not expect the
> following line:
>
> cout << (x=0) << "," << ++x << endl;
>
> produce:
>
> 0,1
>

That code is unproblematic, aside from the fact that it is trying to do far
too many things in a single expression. Problems arise when, for example,
we introduce aliasing:

y = 1;
std::cout << (x = 0) << "," << ++y << '\n';

It is unreasonable to expect the implementation to produce "0,2" in the
case where x and y do not alias but "0,1" in the case where they 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/CAJnLdOYZ_UWUX%2B%3DWe5W68d2rQgcNdViU0dQOVBFb4DgYOVT7Nw%40mail.gmail.com.

--001a113ecbe4c3f063052dafb8e3
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, Mar 10, 2016 at 8:47 AM, Farid Mehrabi <span dir=3D"ltr">&lt;<a href=3D=
"mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.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"rtl"><d=
iv style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" =
dir=3D"ltr">I see to main excuses for rejecting a proper evaluation orderin=
g in the whole discussion:</div><div style=3D"font-family:&#39;arial narrow=
&#39;,sans-serif;font-size:large" dir=3D"ltr">1. projection of shortcomings=
 of compiler designers minority over the majority of programmers( many of w=
hom running from C++ for good reasons).</div></div></blockquote><div><br></=
div><div>I don&#39;t understand this point. What &quot;shortcomings&quot; a=
re you referring to?</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"rtl"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif=
;font-size:large" dir=3D"ltr">2.Conflicts with optimization.</div><div styl=
e=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"=
ltr"><br></div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;=
font-size:large" dir=3D"ltr">Am I missing anything?</div></div></blockquote=
><div><br></div><div>Yes, as has been discussed ad nauseam already: express=
iveness, maintainability, backwards compatibility.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"rtl"><div style=3D"font-family:&#3=
9;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">here are my rep=
lies for those allebies:</div><div style=3D"font-family:&#39;arial narrow&#=
39;,sans-serif;font-size:large" dir=3D"ltr">1. Aren&#39;t tools the result =
of man&#39;s attempt to make hard tasks easier? Why should one believe that=
 writing efficient code must be hard and reading and maintaining it even ha=
rder?=C2=A0</div></div></blockquote><div><br></div><div>Exactly, which is w=
hy the current rules should be kept; a defined order of evaluation would ma=
ke reading code more involved, maintaining it significantly more complex an=
d writing efficient code all but impossible.</div><div>=C2=A0</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"rtl"><div style=3D"font-family:&#39;aria=
l narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">2. What on earth does=
 optimization have to do with ordering? The golden rule of optimization is =
to enhance overheads while keeping side effects consistent. regardless of o=
rdering, optimization techniques such as CSE can be applied in contexts whe=
re common subexpression doesn&#39;t have any side-effects.OOE can be applie=
d when side-effects of code sequences are proven to be uncorrelated...</div=
></div></blockquote><div><br></div><div>Free order of evaluation is the mos=
t natural way for the programmer to communicate to the implementation that =
side effects are absent or can be assumed to be uncorrelated; this means th=
at there is no need for the compiler to prove anything, which may be diffic=
ult or impossible in the general case. In the (limited) instances where the=
 programmer desires a specific ordering of side effects, the language alrea=
dy provides (multiple) ways to explicitly order evaluation.</div><div>=C2=
=A0</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"rtl"><div style=3D"font=
-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">I do=
n&#39;t care if a specific implementation uses AST or not; What matters to =
me is that the best and most naturally expected order of evaluation is that=
 of precedence and associativity. </div></div></blockquote><div><br></div><=
div>If we had to pick a single order of evaluation, that would be the natur=
al one. Fortunately, there is no need to do so.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"rtl"><div style=3D"font-family:&#39;a=
rial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">What I am asking f=
or, is a strong reason for rejecting a well-organized ordering scheme. I am=
 really curious to know why I should not expect the following line:</div><d=
iv style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" =
dir=3D"ltr"><br></div><div style=3D"font-family:&#39;arial narrow&#39;,sans=
-serif;font-size:large" dir=3D"ltr">cout &lt;&lt; (x=3D0) &lt;&lt; &quot;,&=
quot; &lt;&lt; ++x &lt;&lt; endl;</div><div style=3D"font-family:&#39;arial=
 narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"l=
tr">produce:</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-ser=
if;font-size:large" dir=3D"ltr"><br></div><div style=3D"font-family:&#39;ar=
ial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">0,1</div></div></bl=
ockquote><div><br></div><div>That code is unproblematic, aside from the fac=
t that it is trying to do far too many things in a single expression. Probl=
ems arise when, for example, we introduce aliasing:</div><div><br></div><di=
v>y =3D 1;</div><div>std::cout &lt;&lt; (x =3D 0) &lt;&lt; &quot;,&quot; &l=
t;&lt; ++y &lt;&lt; &#39;\n&#39;;</div><div><br></div><div>It is unreasonab=
le to expect the implementation to produce &quot;0,2&quot; in the case wher=
e x and y do not alias but &quot;0,1&quot; in the case where they do.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYZ_UWUX%2B%3DWe5W68d2rQgcNdViU=
0dQOVBFb4DgYOVT7Nw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYZ_UWU=
X%2B%3DWe5W68d2rQgcNdViU0dQOVBFb4DgYOVT7Nw%40mail.gmail.com</a>.<br />

--001a113ecbe4c3f063052dafb8e3--

.

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

2016-03-10 14:30 GMT+03:30 'Edward Catmur' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org>:

> On Thu, Mar 10, 2016 at 8:47 AM, Farid Mehrabi <farid.mehrabi@gmail.com>
> wrote:
>
>> I see to main excuses for rejecting a proper evaluation ordering in the
>> whole discussion:
>> 1. projection of shortcomings of compiler designers minority over the
>> majority of programmers( many of whom running from C++ for good reasons)=
..
>>
>
> I don't understand this point. What "shortcomings" are you referring to?
>
>
>> 2.Conflicts with optimization.
>>
>> Am I missing anything?
>>
>
> Yes, as has been discussed ad nauseam already: expressiveness,
> maintainability, backwards compatibility.
>

=E2=80=8BBackward compatibility with what? UB? broken code? none portable c=
ode that
might eventually crash in the next release?=E2=80=8B



>
>> here are my replies for those allebies:
>> 1. Aren't tools the result of man's attempt to make hard tasks easier?
>> Why should one believe that writing efficient code must be hard and read=
ing
>> and maintaining it even harder?
>>
>
> Exactly, which is why the current rules should be kept; a defined order o=
f
> evaluation would make reading code more involved, maintaining it
> significantly more complex and writing efficient code all but impossible.
>

=E2=80=8BIn What way? how can u tell by seeing a single statement that in w=
hat
order it is going to be executed?=E2=80=8B
This is the reason I keep using the simple cout example. It is simply
unreadable.


>
>
>> 2. What on earth does optimization have to do with ordering? The golden
>> rule of optimization is to enhance overheads while keeping side effects
>> consistent. regardless of ordering, optimization techniques such as CSE =
can
>> be applied in contexts where common subexpression doesn't have any
>> side-effects.OOE can be applied when side-effects of code sequences are
>> proven to be uncorrelated...
>>
>
> Free order of evaluation is the most natural way for the programmer to
> communicate to the implementation that side effects are absent or can be
> assumed to be uncorrelated;
>

=E2=80=8BWhat is the role of the programmer=E2=80=8B here? how many trained=
 programmers (I
don't even think of the novice) use the  dirty syntax of putting every
parameter in a reference/variable? Is this not lack of expressiveness?
In a language that even inlining is managed by the optimizer and
programmers code is a weak hint, such reasoning does not have any firm
basis.


> this means that there is no need for the compiler to prove anything, whic=
h
> may be difficult or impossible in the general case. In the (limited)
> instances where the programmer desires a specific ordering of side effect=
s,
> the language already provides (multiple) ways to explicitly order
> evaluation.
>

=E2=80=8Bdiscovering side effects involves the analysis of code in which th=
e
machine is more elegant than man. If dependency check and removal of
unreferenced functions/objects is possible, discovering side effects=E2=80=
=8B is
possible too and guidelines do not too complex.


>
>
>> I don't care if a specific implementation uses AST or not; What matters
>> to me is that the best and most naturally expected order of evaluation i=
s
>> that of precedence and associativity.
>>
>
> If we had to pick a single order of evaluation, that would be the natural
> one. Fortunately, there is no need to do so.
>
>
>> What I am asking for, is a strong reason for rejecting a well-organized
>> ordering scheme. I am really curious to know why I should not expect the
>> following line:
>>
>> cout << (x=3D0) << "," << ++x << endl;
>>
>> produce:
>>
>> 0,1
>>
>
> That code is unproblematic, aside from the fact that it is trying to do
> far too many things in a single expression.
>

=E2=80=8BThat is exactly the point of this discussion. Those are the proble=
ms
needed to be removed. But they reside in the compiler and the std, rather
than the=E2=80=8B code. It is hard to teach and takes a lot of experience t=
o
learn;That is one reason many fear to face C++.


> Problems arise when, for example, we introduce aliasing:
>
> =E2=80=8B=E2=80=8B
> y =3D 1;
> std::cout << (x =3D 0) << "," << ++y << '\n';
>
>
=E2=80=8Bassuming:

auto& y=3Dx;
=E2=80=8B
y =3D 1;
std::cout << (x =3D 0) << "," << ++y << '\n';

the problem is not in the last line, it is the ill form of the program
which is -IMHO- OT here.



> It is unreasonable to expect the implementation to produce "0,2" in the
> case where x and y do not alias but "0,1" in the case where they do.
>

=E2=80=8Bagreed. but this is not the problem of evaluation order, it is bad=
 coding
practice.=E2=80=8B


=E2=80=8BRegards,
FM.=E2=80=8B


--=20
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

--=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/CALDL7dF8oCtAXAS2tNrVfR99sjwzCPLUYV4TCKLNiREp1Pt=
%3DaQ%40mail.gmail.com.

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

<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:&#39;ari=
al narrow&#39;,sans-serif;font-size:large"><br></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote"><div dir=3D"ltr">2016-03-10 14:30 GMT+0=
3:30 &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span =
dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blan=
k">std-proposals@isocpp.org</a>&gt;</span>:</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;border-right-width:1px;border-right=
-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-r=
ight:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><span class=3D"">On Thu, Mar 10, 2016 at 8:47 AM, Farid Mehrabi <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:farid.mehrabi@gmail.com" target=3D"_blan=
k">farid.mehrabi@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div d=
ir=3D"rtl"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font=
-size:large" dir=3D"ltr">I see to main excuses for rejecting a proper evalu=
ation ordering in the whole discussion:</div><div style=3D"font-family:&#39=
;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">1. projection of=
 shortcomings of compiler designers minority over the majority of programme=
rs( many of whom running from C++ for good reasons).</div></div></blockquot=
e><div><br></div></span><div>I don&#39;t understand this point. What &quot;=
shortcomings&quot; are you referring to?</div><span class=3D""><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"rtl"><div style=3D"font-family:&#39;arial=
 narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">2.Conflicts with optim=
ization.</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large" dir=3D"ltr"><br></div><div style=3D"font-family:&#39;arial =
narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">Am I missing anything?<=
/div></div></blockquote><div><br></div></span><div>Yes, as has been discuss=
ed ad nauseam already: expressiveness, maintainability, backwards compatibi=
lity.</div></div></div></div></blockquote><div>=C2=A0</div><div style=3D"di=
rection:ltr"><div class=3D"gmail_default" style=3D"font-family:&#39;arial n=
arrow&#39;,sans-serif;font-size:large;display:inline">=E2=80=8BBackward com=
patibility with what? UB? broken code? none portable code that might eventu=
ally crash in the next release?=E2=80=8B</div>=C2=A0</div><div style=3D"dir=
ection:ltr"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);bor=
der-right-style:solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><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-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"rtl"><div style=3D"font-family:&#=
39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">here are my re=
plies for those allebies:</div><div style=3D"font-family:&#39;arial narrow&=
#39;,sans-serif;font-size:large" dir=3D"ltr">1. Aren&#39;t tools the result=
 of man&#39;s attempt to make hard tasks easier? Why should one believe tha=
t writing efficient code must be hard and reading and maintaining it even h=
arder?=C2=A0</div></div></blockquote><div><br></div></span><div>Exactly, wh=
ich is why the current rules should be kept; a defined order of evaluation =
would make reading code more involved, maintaining it significantly more co=
mplex and writing efficient code all but impossible.</div></div></div></div=
></blockquote><div>=C2=A0</div><div style=3D"direction:ltr"><div class=3D"g=
mail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-s=
ize:large;display:inline">=E2=80=8BIn What way? how can u tell by seeing a =
single statement that in what order it is going to be executed?=E2=80=8B</d=
iv></div><div style=3D"direction:ltr"><div class=3D"gmail_default" style=3D=
"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large;display:inli=
ne">This is the reason I keep using the simple cout example. It is simply u=
nreadable.</div></div><div style=3D"direction:ltr">=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1p=
x;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left=
:1ex;padding-right:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><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-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
 dir=3D"rtl"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;fo=
nt-size:large" dir=3D"ltr">2. What on earth does optimization have to do wi=
th ordering? The golden rule of optimization is to enhance overheads while =
keeping side effects consistent. regardless of ordering, optimization techn=
iques such as CSE can be applied in contexts where common subexpression doe=
sn&#39;t have any side-effects.OOE can be applied when side-effects of code=
 sequences are proven to be uncorrelated...</div></div></blockquote><div><b=
r></div></span><div>Free order of evaluation is the most natural way for th=
e programmer to communicate to the implementation that side effects are abs=
ent or can be assumed to be uncorrelated;</div></div></div></div></blockquo=
te><div style=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><div=
 class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-s=
erif;font-size:large">=E2=80=8BWhat is the role of the programmer=E2=80=8B =
here? how many trained programmers (I don&#39;t even think of the novice) u=
se the =C2=A0dirty syntax of putting every parameter in a reference/variabl=
e? Is this not lack of expressiveness?</div><div class=3D"gmail_default" st=
yle=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">In a =
language that even inlining is managed by the optimizer and programmers cod=
e is a weak hint, such reasoning does not have any firm basis.</div></div><=
div style=3D"direction:ltr">=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;border-right-width:1px;border-right-color:rg=
b(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"=
><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><di=
v> this means that there is no need for the compiler to prove anything, whi=
ch may be difficult or impossible in the general case. In the (limited) ins=
tances where the programmer desires a specific ordering of side effects, th=
e language already provides (multiple) ways to explicitly order evaluation.=
</div></div></div></div></blockquote><div style=3D"direction:ltr"><br></div=
><div style=3D"direction:ltr"><div class=3D"gmail_default" style=3D"font-fa=
mily:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8Bdiscoverin=
g side effects involves the analysis of code in which the machine is more e=
legant than man. If dependency check and removal of unreferenced functions/=
objects is possible, discovering side effects=E2=80=8B is possible too and =
guidelines do not too complex.=C2=A0</div></div><div style=3D"direction:ltr=
">=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;border-right-width:1px;border-right-color:rgb(204,204,204);border-righ=
t-style:solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><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"rtl"><div style=3D"font-family:&#39;arial=
 narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">I don&#39;t care if a =
specific implementation uses AST or not; What matters to me is that the bes=
t and most naturally expected order of evaluation is that of precedence and=
 associativity. </div></div></blockquote><div><br></div></span><div>If we h=
ad to pick a single order of evaluation, that would be the natural one. For=
tunately, there is no need to do so.</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-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"rtl"><div style=3D"font-family:&#39;arial nar=
row&#39;,sans-serif;font-size:large" dir=3D"ltr">What I am asking for, is a=
 strong reason for rejecting a well-organized ordering scheme. I am really =
curious to know why I should not expect the following line:</div><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"l=
tr"><br></div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large" dir=3D"ltr">cout &lt;&lt; (x=3D0) &lt;&lt; &quot;,&quot; &l=
t;&lt; ++x &lt;&lt; endl;</div><div style=3D"font-family:&#39;arial narrow&=
#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div style=3D"font-f=
amily:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">produc=
e:</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-si=
ze:large" dir=3D"ltr"><br></div><div style=3D"font-family:&#39;arial narrow=
&#39;,sans-serif;font-size:large" dir=3D"ltr">0,1</div></div></blockquote><=
div><br></div></span><div>That code is unproblematic, aside from the fact t=
hat it is trying to do far too many things in a single expression.</div></d=
iv></div></div></blockquote><div style=3D"direction:ltr"><br></div><div sty=
le=3D"direction:ltr"><div class=3D"gmail_default" style=3D"font-family:&#39=
;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8BThat is exactly the=
 point of this discussion. Those are the problems needed to be removed. But=
 they reside in the compiler and the std, rather than the=E2=80=8B code. It=
 is hard to teach and takes a lot of experience to learn;That is one reason=
 many fear to face C++.</div></div><div style=3D"direction:ltr">=C2=A0<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;bord=
er-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:s=
olid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><div> Problems arise when, for example=
, we introduce aliasing:</div><div><br></div><div><div class=3D"gmail_defau=
lt" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large;=
display:inline">=E2=80=8B=E2=80=8B</div>y =3D 1;</div><div>std::cout &lt;&l=
t; (x =3D 0) &lt;&lt; &quot;,&quot; &lt;&lt; ++y &lt;&lt; &#39;\n&#39;;</di=
v><div><br></div></div></div></div></blockquote><div style=3D"direction:ltr=
"><br></div><div style=3D"direction:ltr"><div class=3D"gmail_default" style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=
=8Bassuming:</div><div class=3D"gmail_default" style=3D"font-family:&#39;ar=
ial narrow&#39;,sans-serif;font-size:large"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:la=
rge">auto&amp; y=3Dx;</div><div class=3D"gmail_default" style=3D"font-famil=
y:&#39;arial narrow&#39;,sans-serif;font-size:large"><div style=3D"font-fam=
ily:arial,sans-serif;font-size:small"><div class=3D"gmail_default" style=3D=
"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large;display:inli=
ne">=E2=80=8B</div>y =3D 1;</div><div style=3D"font-family:arial,sans-serif=
;font-size:small">std::cout &lt;&lt; (x =3D 0) &lt;&lt; &quot;,&quot; &lt;&=
lt; ++y &lt;&lt; &#39;\n&#39;;</div></div><div class=3D"gmail_default" styl=
e=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;=
,sans-serif;font-size:large">the problem is not in the last line, it is the=
 ill form of the program which is -IMHO- OT here.</div><br></div><div style=
=3D"direction:ltr">=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204=
,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><=
div>It is unreasonable to expect the implementation to produce &quot;0,2&qu=
ot; in the case where x and y do not alias but &quot;0,1&quot; in the case =
where they do.</div></div></div></div><span class=3D""></span></blockquote>=
<div style=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><div cl=
ass=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-seri=
f;font-size:large">=E2=80=8Bagreed. but this is not the problem of evaluati=
on order, it is bad coding practice.=E2=80=8B</div><br></div><div style=3D"=
direction:ltr"><br></div><div style=3D"direction:ltr"><div class=3D"gmail_d=
efault" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:la=
rge">=E2=80=8BRegards,</div><div class=3D"gmail_default" style=3D"font-fami=
ly:&#39;arial narrow&#39;,sans-serif;font-size:large">FM.=E2=80=8B</div><br=
></div></div><div><br></div>-- <br><div class=3D"gmail_signature"><div dir=
=3D"rtl"><div><div dir=3D"ltr">how am I supposed to end the twisted road of=
=C2=A0 your hair in such a dark night??<br>unless the candle of your face d=
oes shed some light upon my way!!!<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dF8oCtAXAS2tNrVfR99sjwzCPLUYV4T=
CKLNiREp1Pt%3DaQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dF8oCtAXA=
S2tNrVfR99sjwzCPLUYV4TCKLNiREp1Pt%3DaQ%40mail.gmail.com</a>.<br />

--001a113a8110359d8b052db0c6f2--

.

------=_Part_634_1997737495.1457613199089
Content-Type: multipart/alternative;
 boundary="----=_Part_635_158782918.1457613199089"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=884:48:25=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
> I see to main excuses for rejecting a proper evaluation ordering in the=
=20
> whole discussion:
> 1. projection of shortcomings of compiler designers minority over the=20
> majority of programmers( many of whom running from C++ for good reasons).
> 2.Conflicts with optimization.
>
> It is nothing to do with compiler designers. You are not required to trai=
n=20
your brain evaluate the expressions like compilers; you also have no ways=
=20
to force others to change their habits to read code LTR, RTL, and so on, *u=
ntil=20
*you change the *specification *of the language.

I don't think specifying evaluation order is always bad. But it is bad to *=
replace=20
all *unsequenced evaluation.
=20

> Am I missing anything? here are my replies for those allebies:
> 1. Aren't tools the result of man's attempt to make hard tasks easier? Wh=
y=20
> should one believe that writing efficient code must be hard and reading a=
nd=20
> maintaining it even harder?=20
> 2. What on earth does optimization have to do with ordering? The golden=
=20
> rule of optimization is to enhance overheads while keeping side effects=
=20
> consistent. regardless of ordering, optimization techniques such as CSE c=
an=20
> be applied in contexts where common subexpression doesn't have any=20
> side-effects.OOE can be applied when side-effects of code sequences are=
=20
> proven to be uncorrelated...
>
> I don't care if a specific implementation uses AST or not; What matters t=
o=20
> me is that the best and most naturally expected order of evaluation is th=
at=20
> of precedence and associativity. What I am asking for, is a strong reason=
=20
> for rejecting a well-organized ordering scheme. I am really curious to kn=
ow=20
> why I should not expect the following line:
>
> cout << (x=3D0) << "," << ++x << endl;
>
> produce:
>
> 0,1
>
> Things are different to me. I'm not happy to be forced always read or=20
write code in the same order with evaluation order, because those orders=20
are irrelevant in nature. It's illogical to combine different orders into=
=20
one. Both the language itself and practical conforming implementations work=
=20
more similar to my way than yours, so you are introducing a "(pretending)=
=20
to be natural as you expected" intermediate layer in your mind. To assert=
=20
such an artificial way to be "natural" is like premature optimization, if=
=20
not unsound.
=20

> regards,
> FM.
>
>
> 2016-03-10 10:04 GMT+03:30 'Edward Catmur' via ISO C++ Standard - Future=
=20
> Proposals <std-pr...@isocpp.org <javascript:>>:
>
>
> On 10 Mar 2016 00:07, "Dilip Ranganathan" <misc....@gmail.com=20
> <javascript:>> wrote:
> >
> > On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke <mwoehlk...@gmail.com=
=20
> <javascript:>> wrote:
> >>
> >> On 2016-03-09 15:56, Hyman Rosen wrote:
> >> > Specifying order of evaluation increases expressiveness because it=
=20
> makes
> >> > programs legal that are now illegal.
> >>
> >> Uh... what? It *might* cause programs that are incorrect due to wrong
> >> expectations about unspecified behavior to become correct. It might al=
so
> >> do the opposite. In no way, however, are such programs "illegal".
> >
> >
> > What is the opposite? The order today is unspecified. There cannot=20
> be _any_ expectations by definition. Any code that even remotely relies o=
n=20
> such expectation is already broken. Specifying an order will only make it=
=20
> fail consistently *every single time*! Why is this so hard to get across?=
=20
> > =20
>
> You can ask your vendor for an assurance that they will honor your=20
> expectation, and right now they can provide such an assurance. This can b=
e=20
> explicit or a more general commitment to backward compatibility, or just =
an=20
> assurance that no major changes to program translation will occur. Under =
a=20
> specified order the vendor may be forced to repudiate that assurance.=20
>
> Implementations are not required to document unspecified behavior, but=20
> there is nothing to prevent them from doing so if they wish.=20
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Stand
>
> ...

--=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/f9b09262-6add-4bbb-a60e-9a8adcb49d18%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=884:48:25=EF=BC=8CFarid Mehrabi=
=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"rtl"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large" dir=3D"ltr">I see to main excuses for rejecting a proper ev=
aluation ordering in the whole discussion:</div><div style=3D"font-family:&=
#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">1. projection=
 of shortcomings of compiler designers minority over the majority of progra=
mmers( many of whom running from C++ for good reasons).</div><div style=3D"=
font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">=
2.Conflicts with optimization.</div><div style=3D"font-family:&#39;arial na=
rrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div></div></blockqu=
ote><div>It is nothing to do with compiler designers. You are not required =
to train your brain evaluate the expressions like compilers; you also have =
no ways to force others to change their habits to read code LTR, RTL, and s=
o on, <i>until </i>you change the <i>specification </i>of the language.<br>=
<br>I don&#39;t think specifying evaluation order is always bad. But it is =
bad to <i>replace all </i>unsequenced evaluation.<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"rtl"><div style=3D"font-=
family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"></div=
><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:larg=
e" dir=3D"ltr">Am I missing anything? here are my replies for those allebie=
s:</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-si=
ze:large" dir=3D"ltr">1. Aren&#39;t tools the result of man&#39;s attempt t=
o make hard tasks easier? Why should one believe that writing efficient cod=
e must be hard and reading and maintaining it even harder?=C2=A0</div><div =
style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=
=3D"ltr">2. What on earth does optimization have to do with ordering? The g=
olden rule of optimization is to enhance overheads while keeping side effec=
ts consistent. regardless of ordering, optimization techniques such as CSE =
can be applied in contexts where common subexpression doesn&#39;t have any =
side-effects.OOE can be applied when side-effects of code sequences are pro=
ven to be uncorrelated...</div><div style=3D"font-family:&#39;arial narrow&=
#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div style=3D"font-f=
amily:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">I don&=
#39;t care if a specific implementation uses AST or not; What matters to me=
 is that the best and most naturally expected order of evaluation is that o=
f precedence and associativity. What I am asking for, is a strong reason fo=
r rejecting a well-organized ordering scheme. I am really curious to know w=
hy I should not expect the following line:</div><div style=3D"font-family:&=
#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><di=
v style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" d=
ir=3D"ltr">cout &lt;&lt; (x=3D0) &lt;&lt; &quot;,&quot; &lt;&lt; ++x &lt;&l=
t; endl;</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large" dir=3D"ltr"><br></div><div style=3D"font-family:&#39;arial =
narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">produce:</div><div styl=
e=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"=
ltr"><br></div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;=
font-size:large" dir=3D"ltr">0,1</div><div style=3D"font-family:&#39;arial =
narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div></div></block=
quote><div> Things are different to me. I&#39;m not happy to be forced alwa=
ys read or write code in the same order=20
with evaluation order, because those orders are irrelevant in nature.=20
It&#39;s illogical to combine different orders into one. Both the language =
itself and practical conforming implementations work more similar to my way=
 than yours, so you are introducing a &quot;(pretending) to be natural as y=
ou expected&quot; intermediate layer in your mind. To assert such an artifi=
cial way to be &quot;natural&quot; is like premature optimization, if not u=
nsound.<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"rtl"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large" dir=3D"ltr"></div><div style=3D"font-family:&#39;arial narr=
ow&#39;,sans-serif;font-size:large" dir=3D"ltr">regards,</div><div style=3D=
"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"=
>FM.</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large" dir=3D"ltr"><br></div></div><div><br><div><div dir=3D"ltr">2016=
-03-10 10:04 GMT+03:30 &#39;Edward Catmur&#39; via ISO C++ Standard - Futur=
e Proposals <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"APpvk2HUBgAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">std-pr...@isocpp.org</a>&gt;</span>:</div><blo=
ckquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><span><p dir=3D"ltr"><br>
On 10 Mar 2016 00:07, &quot;Dilip Ranganathan&quot; &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"APpvk2HUBgAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">misc....@gmail.com</a>&=
gt; wrote:<br>
&gt;<br>
&gt; On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke &lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"APpvk2HUBgAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">mwoehlk...@gmail.com</a=
>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 2016-03-09 15:56, Hyman Rosen wrote:<br>
&gt;&gt; &gt; Specifying order of evaluation increases expressiveness becau=
se it makes<br>
&gt;&gt; &gt; programs legal that are now illegal.<br>
&gt;&gt;<br>
&gt;&gt; Uh... what? It *might* cause programs that are incorrect due to wr=
ong<br>
&gt;&gt; expectations about unspecified behavior to become correct. It migh=
t also<br>
&gt;&gt; do the opposite. In no way, however, are such programs &quot;illeg=
al&quot;.<br>
&gt;<br>
&gt;<br>
&gt; What is the opposite?=C2=A0The order today is unspecified. There canno=
t be=C2=A0_any_ expectations by definition. Any code that even remotely=C2=
=A0relies on such expectation=C2=A0is already broken.=C2=A0Specifying an or=
der will only make it fail consistently *every single time*! Why is this so=
 hard to get across?=C2=A0<br>
&gt; =C2=A0</p>
</span><p dir=3D"ltr">You can ask your vendor for an assurance that they wi=
ll honor your expectation, and right now they can provide such an assurance=
.. This can be explicit or a more general commitment to backward compatibili=
ty, or just an assurance that no major changes to program translation will =
occur. Under a specified order the vendor may be forced to repudiate that a=
ssurance. </p>
<p dir=3D"ltr">Implementations are not required to document unspecified beh=
avior, but there is nothing to prevent them from doing so if they wish. </p=
><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Stand</span></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f9b09262-6add-4bbb-a60e-9a8adcb49d18%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f9b09262-6add-4bbb-a60e-9a8adcb49d18=
%40isocpp.org</a>.<br />

------=_Part_635_158782918.1457613199089--
------=_Part_634_1997737495.1457613199089--

.

------=_Part_681_1283982082.1457617220921
Content-Type: multipart/alternative;
 boundary="----=_Part_682_804416837.1457617220922"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=888:15:49=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> 2016-03-10 14:30 GMT+03:30 'Edward Catmur' via ISO C++ Standard - Future=
=20
> Proposals <std-pr...@isocpp.org <javascript:>>:
>
> On Thu, Mar 10, 2016 at 8:47 AM, Farid Mehrabi <farid....@gmail.com=20
> <javascript:>> wrote:
>
> I see to main excuses for rejecting a proper evaluation ordering in the=
=20
> whole discussion:
> 1. projection of shortcomings of compiler designers minority over the=20
> majority of programmers( many of whom running from C++ for good reasons).
>
>
> I don't understand this point. What "shortcomings" are you referring to?
> =20
>
> 2.Conflicts with optimization.
>
> Am I missing anything?
>
>
> Yes, as has been discussed ad nauseam already: expressiveness,=20
> maintainability, backwards compatibility.
>
> =20
> =E2=80=8BBackward compatibility with what? UB? broken code? none portable=
 code=20
> that might eventually crash in the next release?=E2=80=8B
> =20
>
> Backward to the freedom of keeping the different things being different i=
n=20
a natural way, rather than pretending they are the same by reducing=20
expressiveness. You can't eliminate the essential difference via the=20
specification until you rewrite "phases of translations" rules totally. Ask=
=20
the committee if anyone can afford this.
=20

> =20
>
> here are my replies for those allebies:
> 1. Aren't tools the result of man's attempt to make hard tasks easier? Wh=
y=20
> should one believe that writing efficient code must be hard and reading a=
nd=20
> maintaining it even harder?=20
>
>
> Exactly, which is why the current rules should be kept; a defined order o=
f=20
> evaluation would make reading code more involved, maintaining it=20
> significantly more complex and writing efficient code all but impossible.
>
> =20
> =E2=80=8BIn What way? how can u tell by seeing a single statement that in=
 what=20
> order it is going to be executed?=E2=80=8B
> This is the reason I keep using the simple cout example. It is simply=20
> unreadable.
> =20
>
This style (so-called fluent interface) of interface design is simply=20
broken. It is nothing wrong to be unreadable as the consequence. Only when=
=20
you admit the difference between literal order and evaluation order, it can=
=20
work (a little). That's the status quo.
=20
Changing the evaluation rules don't change the reason why such style is=20
bad. It just hide the dark side.

What is a better style? Keep in mind: do one thing in one time, and do it=
=20
well enough. Well, cout? Far from this. It even has other nasty "features"=
=20
that make it unusable for most of users like you. Do you know=20
'sync_with_stdio'?

=20
>
> 2. What on earth does optimization have to do with ordering? The golden=
=20
> rule of optimization is to enhance overheads while keeping side effects=
=20
> consistent. regardless of ordering, optimization techniques such as CSE c=
an=20
> be applied in contexts where common subexpression doesn't have any=20
> side-effects.OOE can be applied when side-effects of code sequences are=
=20
> proven to be uncorrelated...
>
>
> Free order of evaluation is the most natural way for the programmer to=20
> communicate to the implementation that side effects are absent or can be=
=20
> assumed to be uncorrelated;
>
>
> =E2=80=8BWhat is the role of the programmer=E2=80=8B here?
>
The one who need to obey the rules designed by those who though more, if he=
=20
is reluctant to reason the rationale.
=20

> how many trained programmers (I don't even think of the novice) use the=
=20
>  dirty syntax of putting every parameter in a reference/variable?
>
Most trained users should clearly know it is dangerous to rely on the=20
fictional evaluation order they expected. Few people will write f(x =3D y, =
z=20
=3D w) even when it is safe. (Note they put the arguments, not parameters.)
=20
But let me say, most of them are not well-trained to talk about most of=20
things here. They do not know how and why these rules are deliberately=20
designed, and which parts of the language specification are tied with it.=
=20
This is nothing wrong because they are not trained to be programing=20
language theorists or compiler writers. They may even have too little time=
=20
to write programs. Nevertheless, they may design software or other products=
=20
perfectly, with the way totally different to serious coding. However, I=20
don't believe they can change the essential design of a general-purpose=20
language smoothly in a convincing and indisputable way without the=20
necessary background knowledge.

Is this not lack of expressiveness?
> In a language that even inlining is managed by the optimizer and=20
> programmers code is a weak hint, such reasoning does not have any firm=20
> basis.
> =20
>
Expressiveness is not only to "express what you want". One should first=20
point out and explain how it can exist in a language by permission of rules=
=20
of the specification. Then he can illustrate why it should be expressive. A=
=20
simple way is comparison: if you can show me something provides strictly=20
more desired semantics properties, it is more expressive. Once that=20
expressiveness has practical use, it should be kept.

Inlining has nothing to do with expressiveness, because it is totally not=
=20
mandated by the language. C++ has no such expressiveness all the time.=20
(Note extensions provided by dialects are not parts of C++.)

If you are talking about the 'inline' keyword, it does have expressiveness=
=20
on effect about obeying the one definition rule. Whether to inline the=20
translated code or not is irrelevant, even the etymology was historically=
=20
concerned with.
=20

> this means that there is no need for the compiler to prove anything, whic=
h=20
> may be difficult or impossible in the general case. In the (limited)=20
> instances where the programmer desires a specific ordering of side effect=
s,=20
> the language already provides (multiple) ways to explicitly order=20
> evaluation.
>
>
> =E2=80=8Bdiscovering side effects involves the analysis of code in which =
the=20
> machine is more elegant than man. If dependency check and removal of=20
> unreferenced functions/objects is possible, discovering side effects=E2=
=80=8B is=20
> possible too and guidelines do not too complex.=20
>

No. Machines can work harder, but never guarantees to do the work better,=
=20
since it can't effectively know what humans need. Machines may do some=20
simple works equally good and with less cost, so just let machines to=20
replace humans in such cases. Not all things are simple to machines.=20
Dependency check and removal of unreferenced functions/objects may be=20
simple, true. However, to deduce the correct order with side effects is=20
definitely not in general. Unspecified evaluation order is a shortcut to=20
avoid the difficult proving work, and machines can hardly do such work=20
without it. As-if rules permit it is not impossible, but only with as-if=20
rules it may be nearly impossible. Without the hint provided by deliberated=
=20
unspecified evaluation order, even humans can do almost nothing better at=
=20
the level of program transformation (though reducing expressiveness=20
aggravates the difference between humans and machines). So this is=20
essentially not only concerned with "optimization" performed by machines.

=20
>
> =20
>
> I don't care if a specific implementation uses AST or not; What matters t=
o=20
> me is that the best and most naturally expected order of evaluation is th=
at=20
> of precedence and associativity.=20
>
>
> If we had to pick a single order of evaluation, that would be the natural=
=20
> one. Fortunately, there is no need to do so.
> =20
>
> What I am asking for, is a strong reason for rejecting a well-organized=
=20
> ordering scheme. I am really curious to know why I should not expect the=
=20
> following line:
>
> cout << (x=3D0) << "," << ++x << endl;
>
> produce:
>
> 0,1
>
>
> That code is unproblematic, aside from the fact that it is trying to do=
=20
> far too many things in a single expression.
>
>
> =E2=80=8BThat is exactly the point of this discussion. Those are the prob=
lems=20
> needed to be removed. But they reside in the compiler and the std, rather=
=20
> than the=E2=80=8B code. It is hard to teach and takes a lot of experience=
 to=20
> learn;That is one reason many fear to face C++.
> =20
>
I don't think this is unproblematic since I can only roughly guess what the=
=20
author of the code want to do with the assumption (of language rule) not=20
actually valid. I don't think to support the "trying to do far too many=20
things in a single expression" is the right direction. Allowing this style=
=20
is essentially encouraging such poor/hard-to-read code.
=20

> Problems arise when, for example, we introduce aliasing:
>
> =E2=80=8B=E2=80=8B
> y =3D 1;
> std::cout << (x =3D 0) << "," << ++y << '\n';
>
>
> =E2=80=8Bassuming:
> ...

--=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/93a8a4c9-29d8-4cfb-8980-4dd49269d7c3%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=888:15:49=EF=BC=8CFarid Mehrabi=
=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"rtl"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large"><br></div><div><br><div><div dir=3D"ltr">2016-03-10 14:30 G=
MT+03:30 &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"Wtrn57LfBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">std-pr...@isocpp.org</a>&gt;</span>:</div><blockquote style=
=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;border-right-width:1px;border-right-color:rgb(20=
4,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"><di=
v dir=3D"ltr"><div><div><span>On Thu, Mar 10, 2016 at 8:47 AM, Farid Mehrab=
i <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"Wtrn57LfBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">farid....@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 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"rtl"=
><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:larg=
e" dir=3D"ltr">I see to main excuses for rejecting a proper evaluation orde=
ring in the whole discussion:</div><div style=3D"font-family:&#39;arial nar=
row&#39;,sans-serif;font-size:large" dir=3D"ltr">1. projection of shortcomi=
ngs of compiler designers minority over the majority of programmers( many o=
f whom running from C++ for good reasons).</div></div></blockquote><div><br=
></div></span><div>I don&#39;t understand this point. What &quot;shortcomin=
gs&quot; are you referring to?</div><span><div>=C2=A0</div><blockquote 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"rtl"><div=
 style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" di=
r=3D"ltr">2.Conflicts with optimization.</div><div style=3D"font-family:&#3=
9;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div =
style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=
=3D"ltr">Am I missing anything?</div></div></blockquote><div><br></div></sp=
an><div>Yes, as has been discussed ad nauseam already: expressiveness, main=
tainability, backwards compatibility.</div></div></div></div></blockquote><=
div>=C2=A0</div><div style=3D"direction:ltr"><div style=3D"font-family:&#39=
;arial narrow&#39;,sans-serif;font-size:large;display:inline">=E2=80=8BBack=
ward compatibility with what? UB? broken code? none portable code that migh=
t eventually crash in the next release?=E2=80=8B</div>=C2=A0</div><div styl=
e=3D"direction:ltr"><br></div></div></div></div></blockquote><div>Backward =
to the freedom of keeping the different things being different in a natural=
 way, rather than pretending they are the same by reducing expressiveness. =
You can&#39;t eliminate the essential difference via the specification unti=
l you rewrite &quot;phases of translations&quot; rules totally. Ask the com=
mittee if anyone can afford this.<br>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"rtl"><div><div><div style=3D"direction:l=
tr"></div><blockquote style=3D"margin:0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1p=
x;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left=
:1ex;padding-right:1ex"><div dir=3D"ltr"><div><div><span><div>=C2=A0</div><=
blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div d=
ir=3D"rtl"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font=
-size:large" dir=3D"ltr">here are my replies for those allebies:</div><div =
style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=
=3D"ltr">1. Aren&#39;t tools the result of man&#39;s attempt to make hard t=
asks easier? Why should one believe that writing efficient code must be har=
d and reading and maintaining it even harder?=C2=A0</div></div></blockquote=
><div><br></div></span><div>Exactly, which is why the current rules should =
be kept; a defined order of evaluation would make reading code more involve=
d, maintaining it significantly more complex and writing efficient code all=
 but impossible.</div></div></div></div></blockquote><div>=C2=A0</div><div =
style=3D"direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sa=
ns-serif;font-size:large;display:inline">=E2=80=8BIn What way? how can u te=
ll by seeing a single statement that in what order it is going to be execut=
ed?=E2=80=8B</div></div><div style=3D"direction:ltr"><div style=3D"font-fam=
ily:&#39;arial narrow&#39;,sans-serif;font-size:large;display:inline">This =
is the reason I keep using the simple cout example. It is simply unreadable=
..</div></div><div style=3D"direction:ltr">=C2=A0</div></div></div></div></b=
lockquote><div>This style (so-called fluent interface) of interface design =
is simply broken. It is nothing wrong to be unreadable as the consequence. =
Only when you admit the difference between literal order and evaluation ord=
er, it can work (a little). That&#39;s the status quo.<br>=C2=A0<br>Changin=
g the evaluation rules don&#39;t change the reason why such style is bad. I=
t just hide the dark side.<br><br>What is a better style? Keep in mind: do =
one thing in one time, and do it well enough. Well, cout? Far from this. It=
 even has other nasty &quot;features&quot; that make it unusable for most o=
f users like you. Do you know &#39;sync_with_stdio&#39;?<br><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"rtl"><div><div><blockqu=
ote style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;border-right-width:1px;border-right-col=
or:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right=
:1ex"><div dir=3D"ltr"><div><div><span><div>=C2=A0</div><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"rtl"><div =
style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=
=3D"ltr">2. What on earth does optimization have to do with ordering? The g=
olden rule of optimization is to enhance overheads while keeping side effec=
ts consistent. regardless of ordering, optimization techniques such as CSE =
can be applied in contexts where common subexpression doesn&#39;t have any =
side-effects.OOE can be applied when side-effects of code sequences are pro=
ven to be uncorrelated...</div></div></blockquote><div><br></div></span><di=
v>Free order of evaluation is the most natural way for the programmer to co=
mmunicate to the implementation that side effects are absent or can be assu=
med to be uncorrelated;</div></div></div></div></blockquote><div style=3D"d=
irection:ltr"><br></div><div style=3D"direction:ltr"><div style=3D"font-fam=
ily:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8BWhat is the=
 role of the programmer=E2=80=8B here?</div></div></div></div></div></block=
quote><div>The one who need to obey the rules designed by those who though =
more, if he is reluctant to reason the rationale.<br>=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"rtl"><div><div><div style=3D=
"direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif=
;font-size:large">how many trained programmers (I don&#39;t even think of t=
he novice) use the =C2=A0dirty syntax of putting every parameter in a refer=
ence/variable?</div></div></div></div></div></blockquote><div>Most trained =
users should clearly know it is dangerous to rely on the fictional evaluati=
on order they expected. Few people will write f(x =3D y, z =3D w) even when=
 it is safe. (Note they put the arguments, not parameters.)<br>=C2=A0<br>Bu=
t let me say, most of them are not well-trained to talk about most of thing=
s here. They do not know how and why these rules are deliberately designed,=
 and which parts of the language specification are tied with it. This is no=
thing wrong because they are not trained to be programing language theorist=
s or compiler writers. They may even have too little time to write programs=
.. Nevertheless, they may design software or other products perfectly, with =
the way totally different to serious coding. However, I don&#39;t believe t=
hey can change the essential design of a general-purpose language smoothly =
in a convincing and indisputable way without the necessary background knowl=
edge.<br><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=
"rtl"><div><div><div style=3D"direction:ltr"><div style=3D"font-family:&#39=
;arial narrow&#39;,sans-serif;font-size:large">Is this not lack of expressi=
veness?</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;fo=
nt-size:large">In a language that even inlining is managed by the optimizer=
 and programmers code is a weak hint, such reasoning does not have any firm=
 basis.</div></div><div style=3D"direction:ltr">=C2=A0</div></div></div></d=
iv></blockquote><div>Expressiveness is not only to &quot;express what you w=
ant&quot;. One should first point out and explain how it can exist in a lan=
guage by permission of rules of the specification. Then he can illustrate w=
hy it should be expressive. A simple way is comparison: if you can show me =
something provides strictly more desired semantics properties, it is more e=
xpressive. Once that expressiveness has practical use, it should be kept.<b=
r><br>Inlining has nothing to do with expressiveness, because it is totally=
 not mandated by the language. C++ has no such expressiveness all the time.=
 (Note extensions provided by dialects are not parts of C++.)<br><br>If you=
 are talking about the &#39;inline&#39; keyword, it does have expressivenes=
s on effect about obeying the one definition rule. Whether to inline the tr=
anslated code or not is irrelevant, even the etymology was historically con=
cerned with.<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"rtl"><div><div><blockquote style=3D"margin:0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;bo=
rder-right-width:1px;border-right-color:rgb(204,204,204);border-right-style=
:solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div><div><div>=
 this means that there is no need for the compiler to prove anything, which=
 may be difficult or impossible in the general case. In the (limited) insta=
nces where the programmer desires a specific ordering of side effects, the =
language already provides (multiple) ways to explicitly order evaluation.</=
div></div></div></div></blockquote><div style=3D"direction:ltr"><br></div><=
div style=3D"direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39=
;,sans-serif;font-size:large">=E2=80=8Bdiscovering side effects involves th=
e analysis of code in which the machine is more elegant than man. If depend=
ency check and removal of unreferenced functions/objects is possible, disco=
vering side effects=E2=80=8B is possible too and guidelines do not too comp=
lex.=C2=A0</div></div><div style=3D"direction:ltr"></div></div></div></div>=
</blockquote><div><br>No. Machines can work harder, but never guarantees to=
 do the work better, since it can&#39;t effectively know what humans need. =
Machines may do some simple works equally good and with less cost, so just =
let machines to replace humans in such cases. Not all things are simple to =
machines. Dependency check and removal of unreferenced functions/objects ma=
y be simple, true. However, to deduce the correct order with side effects i=
s definitely not in general. Unspecified evaluation order is a shortcut to =
avoid the difficult proving work, and machines can hardly do such work with=
out it. As-if rules permit it is not impossible, but only with as-if rules =
it may be nearly impossible. Without the hint provided by deliberated unspe=
cified evaluation order, even humans can do almost nothing better at the le=
vel of program transformation (though reducing expressiveness aggravates th=
e difference between humans and machines). So this is essentially not only =
concerned with &quot;optimization&quot; performed by machines.<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;"><div dir=3D"rtl"><div><div><d=
iv style=3D"direction:ltr">=C2=A0</div><blockquote style=3D"margin:0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-r=
ight-style:solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div>=
<div><span><div>=C2=A0</div><blockquote 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"rtl"><div style=3D"font-family:&#39;aria=
l narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">I don&#39;t care if a=
 specific implementation uses AST or not; What matters to me is that the be=
st and most naturally expected order of evaluation is that of precedence an=
d associativity. </div></div></blockquote><div><br></div></span><div>If we =
had to pick a single order of evaluation, that would be the natural one. Fo=
rtunately, there is no need to do so.</div><span><div>=C2=A0</div><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"rt=
l"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:la=
rge" dir=3D"ltr">What I am asking for, is a strong reason for rejecting a w=
ell-organized ordering scheme. I am really curious to know why I should not=
 expect the following line:</div><div style=3D"font-family:&#39;arial narro=
w&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div style=3D"font=
-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">cout=
 &lt;&lt; (x=3D0) &lt;&lt; &quot;,&quot; &lt;&lt; ++x &lt;&lt; endl;</div><=
div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"=
 dir=3D"ltr"><br></div><div style=3D"font-family:&#39;arial narrow&#39;,san=
s-serif;font-size:large" dir=3D"ltr">produce:</div><div style=3D"font-famil=
y:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div>=
<div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large=
" dir=3D"ltr">0,1</div></div></blockquote><div><br></div></span><div>That c=
ode is unproblematic, aside from the fact that it is trying to do far too m=
any things in a single expression.</div></div></div></div></blockquote><div=
 style=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=
=8BThat is exactly the point of this discussion. Those are the problems nee=
ded to be removed. But they reside in the compiler and the std, rather than=
 the=E2=80=8B code. It is hard to teach and takes a lot of experience to le=
arn;That is one reason many fear to face C++.</div></div><div style=3D"dire=
ction:ltr">=C2=A0<br></div></div></div></div></blockquote><div>I don&#39;t =
think this is unproblematic since I can only roughly guess what the author =
of the code want to do with the assumption (of language rule) not actually =
valid. I don&#39;t think to support the &quot;trying to do far too many thi=
ngs in a single expression&quot; is the right direction. Allowing this styl=
e is essentially encouraging such poor/hard-to-read code.<br>=C2=A0<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"rtl"><div><div><=
div style=3D"direction:ltr"></div><blockquote style=3D"margin:0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-=
style:solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div><div>=
<div> Problems arise when, for example, we introduce aliasing:</div><div><b=
r></div><div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;fo=
nt-size:large;display:inline">=E2=80=8B=E2=80=8B</div>y =3D 1;</div><div>st=
d::cout &lt;&lt; (x =3D 0) &lt;&lt; &quot;,&quot; &lt;&lt; ++y &lt;&lt; &#3=
9;\n&#39;;</div><div><br></div></div></div></div></blockquote><div style=3D=
"direction:ltr"><br></div><div style=3D"direction:ltr"><div style=3D"font-f=
amily:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8Bassuming:=
</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/93a8a4c9-29d8-4cfb-8980-4dd49269d7c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/93a8a4c9-29d8-4cfb-8980-4dd49269d7c3=
%40isocpp.org</a>.<br />

------=_Part_682_804416837.1457617220922--
------=_Part_681_1283982082.1457617220921--

.

On 2016-03-09 19:07, Dilip Ranganathan wrote:
> On Wed, Mar 9, 2016 at 6:11 PM, Matthew Woehlke wrote:
>> On 2016-03-09 15:56, Hyman Rosen wrote:
>>> Specifying order of evaluation increases expressiveness because it makes
>>> programs legal that are now illegal.
>>
>> Uh... what? It *might* cause programs that are incorrect due to wrong
>> expectations about unspecified behavior to become correct. It might also
>> do the opposite. In no way, however, are such programs "illegal".
>
> What is the opposite?

Programs that currently work today due to "correct" (i.e. that match the
compiler behavior) expectations newly operate incorrectly. Which is
exactly what people are complaining about.

(Clarification: "correct" and "incorrect" in the preceding refer to
program behavior, not standard conformance.)

> The order today is unspecified. There cannot be _any_ expectations by
> definition.

You are missing the word "valid" in that sentence. There most certainly
*can* be wrong expectations today. Indeed, if there weren't, we wouldn't
be having this conversation.

> Any code that even remotely relies on such expectation is already
> broken. Specifying an order will only make it fail consistently
> *every single time*! Why is this so hard to get across?

It isn't; I understood that from the start. This is not the claim you
made, however. "Fail consistently" is quite the opposite of "become
newly legal".

>>> Specifying order of evaluation does not take away anyone's freedom.
>>
>> Uh... compiler's freedom? Seriously, how can you say that with a
>> straight face?
>>
>> Removing unspecified behavior *by definition* reduces compiler freedom.
>
> What is the compiler doing with this alleged freedom **today**? Can you
> show me an example of where specifying an order will take away that freedom?

This has been discussed to death already. I doubt anything I can say
will change your opinion here.

The point is, you are making dogmatic statements that, at least from
your opponents' perspective, are *wrong*. That's not a good way to win
an argument. It *is* a good way to get your opponents' emotionally riled
up, which only serves to polarize the issue and make your opponents even
less willing to respond to persuasion.

--
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/nbrup6%242ct%241%40ger.gmane.org.

.

On 2016-03-10 06:00, Edward Catmur wrote:
> Free order of evaluation is the most natural way for the programmer to
> communicate to the implementation that side effects are absent or can be
> assumed to be uncorrelated; this means that there is no need for the
> compiler to prove anything, which may be difficult or impossible in the
> general case.

In the *standard conforming* case, definitely impossible. The language
lacks the tools to express these ideas.

I've said this many times already, but... if we had those tools *first*,
and they were widely employed, I would feel much different about
restricting evaluation order. That we are doing the latter before the
former is IMHO a mistake.

--
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/nbrv52%242ct%242%40ger.gmane.org.

.

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

On Thu, Mar 10, 2016 at 9:02 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

>
> The point is, you are making dogmatic statements that, at least from
> your opponents' perspective, are *wrong*. That's not a good way to win
> an argument. It *is* a good way to get your opponents' emotionally riled
> up, which only serves to polarize the issue and make your opponents even
> less willing to respond to persuasion.
>

More psycho-analysis. I will let that slide. I don't know what you mean by
"dogmatic". We presented a real life situation at work where code relied on
a particular order for as long as I can remember (probably several years)
and our expectations matched that of the compiler giving the impression
that everything was alright -- until one day the compiler decided to break
that assumption causing a semi-major outage.


>
> --
> Matthew
>
> --
> 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/oQUOtYX4R3o/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/nbrup6%242ct%241%40ger.gmane.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/CALEPxfs4goEkUZY%3D50ONvh5Re6-%2BLCgpmfqc5YYOge7heaGqag%40mail.gmail.com.

--001a11c38d52a400a2052db29c88
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, Mar 10, 2016 at 9:02 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The point is, you are making dogmatic statements that, at least from<br>
your opponents&#39; perspective, are *wrong*. That&#39;s not a good way to =
win<br>
an argument. It *is* a good way to get your opponents&#39; emotionally rile=
d<br>
up, which only serves to polarize the issue and make your opponents even<br=
>
less willing to respond to persuasion.<br></blockquote><div><br></div><div>=
More psycho-analysis. I will let that slide. I don&#39;t know what you mean=
 by &quot;dogmatic&quot;. We presented a real life situation at work where =
code relied on a particular order for as long as I can remember (probably s=
everal years) and our expectations matched that of the compiler giving the =
impression that everything was alright -- until one day the compiler decide=
d to break that assumption causing a semi-major outage.=C2=A0</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
<br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/oQUOtYX4R3o/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/oQUOtYX4R3o/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+unsubscrib=
e@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/nbrup6%242ct%241%40ger.gmane.org" rel=
=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/=
msgid/std-proposals/nbrup6%242ct%241%40ger.gmane.org</a>.<br>
</font></span></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxfs4goEkUZY%3D50ONvh5Re6-%2BLCgp=
mfqc5YYOge7heaGqag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfs4goEk=
UZY%3D50ONvh5Re6-%2BLCgpmfqc5YYOge7heaGqag%40mail.gmail.com</a>.<br />

--001a11c38d52a400a2052db29c88--

.

--Apple-Mail=_4CF9050E-D042-4257-BC7F-F2118941662F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

I=E2=80=99ve been following this discussion for weeks now. It has served as=
 a sterling reminder of why I stopped working on CORBA <http://www.triodia.=
com/staff/michi/queue/riseAndFallOfCorba.pdf>.

Too many cooks eternally spoil the broth.

Michi.

--=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/74A2ECF3-DFC3-4B74-9DCB-763268C00559%40canonical=
..com.

--Apple-Mail=_4CF9050E-D042-4257-BC7F-F2118941662F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><div>I=E2=80=
=99ve been following this discussion for weeks now. It has served as a ster=
ling reminder of why&nbsp;<a href=3D"http://www.triodia.com/staff/michi/que=
ue/riseAndFallOfCorba.pdf" class=3D"">I stopped working on CORBA</a>.</div>=
</div><div><br class=3D""></div><div>Too many cooks eternally spoil the bro=
th.</div><div><br class=3D""></div><div>Michi.</div></body></html>

<p></p>

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

--Apple-Mail=_4CF9050E-D042-4257-BC7F-F2118941662F--

.

--047d7bd7585afee667052db2e82d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 10, 2016 at 12:15 PM, Farid Mehrabi <farid.mehrabi@gmail.com>
wrote:

>
> =E2=80=8BBackward compatibility with what? UB? broken code? none portable=
 code
> that might eventually crash in the next release?=E2=80=8B
>
>

The latter, naturally; code targeting a specific platform does not need to
be portable, and new releases do not have to break existing code - unless,
of course, they are forced to by a non-backward-compatible change to the
Standard.


> here are my replies for those allebies:
>>> 1. Aren't tools the result of man's attempt to make hard tasks easier?
>>> Why should one believe that writing efficient code must be hard and rea=
ding
>>> and maintaining it even harder?
>>>
>>
>> Exactly, which is why the current rules should be kept; a defined order
>> of evaluation would make reading code more involved, maintaining it
>> significantly more complex and writing efficient code all but impossible=
..
>>
>
> =E2=80=8BIn What way? how can u tell by seeing a single statement that in=
 what
> order it is going to be executed?=E2=80=8B
> This is the reason I keep using the simple cout example. It is simply
> unreadable.
>

You don't need to know how a statement will be translated to be able to
reason about it; it is enough to know that it will be translated according
to the rules of the language, which means that reading it is easier if the
rules of the language are simpler.


> 2. What on earth does optimization have to do with ordering? The golden
>>> rule of optimization is to enhance overheads while keeping side effects
>>> consistent. regardless of ordering, optimization techniques such as CSE=
 can
>>> be applied in contexts where common subexpression doesn't have any
>>> side-effects.OOE can be applied when side-effects of code sequences are
>>> proven to be uncorrelated...
>>>
>>
>> Free order of evaluation is the most natural way for the programmer to
>> communicate to the implementation that side effects are absent or can be
>> assumed to be uncorrelated;
>>
>
> =E2=80=8BWhat is the role of the programmer=E2=80=8B here? how many train=
ed programmers (I
> don't even think of the novice) use the  dirty syntax of putting every
> parameter in a reference/variable? Is this not lack of expressiveness?
> In a language that even inlining is managed by the optimizer and
> programmers code is a weak hint, such reasoning does not have any firm
> basis.
>

Calculating arguments individually (I assume this is what you mean) seems
perfectly expressive to me if it is the programmer's intent to serialize
their side effects.


> this means that there is no need for the compiler to prove anything, whic=
h
>> may be difficult or impossible in the general case. In the (limited)
>> instances where the programmer desires a specific ordering of side effec=
ts,
>> the language already provides (multiple) ways to explicitly order
>> evaluation.
>>
>
> =E2=80=8Bdiscovering side effects involves the analysis of code in which =
the
> machine is more elegant than man. If dependency check and removal of
> unreferenced functions/objects is possible, discovering side effects=E2=
=80=8B is
> possible too and guidelines do not too complex.
>

Not always, and that still doesn't answer the question of to what extent
side effects need to be serialized. As it is, unspecified order of
evaluation is our best tool to express that.


> What I am asking for, is a strong reason for rejecting a well-organized
>>> ordering scheme. I am really curious to know why I should not expect th=
e
>>> following line:
>>>
>>> cout << (x=3D0) << "," << ++x << endl;
>>>
>>> produce:
>>>
>>> 0,1
>>>
>>
>> That code is unproblematic, aside from the fact that it is trying to do
>> far too many things in a single expression.
>>
>
> =E2=80=8BThat is exactly the point of this discussion. Those are the prob=
lems
> needed to be removed. But they reside in the compiler and the std, rather
> than the=E2=80=8B code. It is hard to teach and takes a lot of experience=
 to
> learn;That is one reason many fear to face C++.
>

Even if order of execution was defined for that snippet, it would still be
bad style.


> Problems arise when, for example, we introduce aliasing:
>>
>> =E2=80=8B=E2=80=8B
>> y =3D 1;
>> std::cout << (x =3D 0) << "," << ++y << '\n';
>>
>>
> =E2=80=8Bassuming:
>
> auto& y=3Dx;
> =E2=80=8B
> y =3D 1;
> std::cout << (x =3D 0) << "," << ++y << '\n';
>
> the problem is not in the last line, it is the ill form of the program
> which is -IMHO- OT here.
>

 I am not assuming that y aliases x. The problem arises when the compiler
cannot prove that x and y do not alias.

It is unreasonable to expect the implementation to produce "0,2" in the
>> case where x and y do not alias but "0,1" in the case where they do.
>>
>
> =E2=80=8Bagreed. but this is not the problem of evaluation order, it is b=
ad coding
> practice.=E2=80=8B
>

What's bad about that code? How is it any worse than your snippet?

--=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/CAJnLdObzc0o4PdbY8OVSTLaGfYd6_dQaG0VTwkQJ3o%2B5h=
Nhz4A%40mail.gmail.com.

--047d7bd7585afee667052db2e82d
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, Mar 10, 2016 at 12:15 PM, Farid Mehrabi <span dir=3D"ltr">&lt;<a href=
=3D"mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.c=
om</a>&gt;</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"rtl"=
><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:larg=
e"><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div sty=
le=3D"direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans-=
serif;font-size:large;display:inline">=E2=80=8BBackward compatibility with =
what? UB? broken code? none portable code that might eventually crash in th=
e next release?=E2=80=8B</div>=C2=A0</div></div></div></div></blockquote><d=
iv><br></div><div>The latter, naturally; code targeting a specific platform=
 does not need to be portable, and new releases do not have to break existi=
ng code - unless, of course, they are forced to by a non-backward-compatibl=
e change to the Standard.</div><div>=C2=A0</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"rtl"><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-ri=
ght-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;=
padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><span><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"rtl"><di=
v style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" d=
ir=3D"ltr">here are my replies for those allebies:</div><div style=3D"font-=
family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">1. Ar=
en&#39;t tools the result of man&#39;s attempt to make hard tasks easier? W=
hy should one believe that writing efficient code must be hard and reading =
and maintaining it even harder?=C2=A0</div></div></blockquote><div><br></di=
v></span><div>Exactly, which is why the current rules should be kept; a def=
ined order of evaluation would make reading code more involved, maintaining=
 it significantly more complex and writing efficient code all but impossibl=
e.</div></div></div></div></blockquote><div>=C2=A0</div><div style=3D"direc=
tion:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large;display:inline">=E2=80=8BIn What way? how can u tell by seeing a=
 single statement that in what order it is going to be executed?=E2=80=8B</=
div></div><div style=3D"direction:ltr"><div style=3D"font-family:&#39;arial=
 narrow&#39;,sans-serif;font-size:large;display:inline">This is the reason =
I keep using the simple cout example. It is simply unreadable.</div></div><=
/div></div></div></blockquote><div><br></div><div>You don&#39;t need to kno=
w how a statement will be translated to be able to reason about it; it is e=
nough to know that it will be translated according to the rules of the lang=
uage, which means that reading it is easier if the rules of the language ar=
e simpler.</div><div>=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"rtl"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;border-right-width=
:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-l=
eft:1ex;padding-right:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div dir=3D"rtl"><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"l=
tr">2. What on earth does optimization have to do with ordering? The golden=
 rule of optimization is to enhance overheads while keeping side effects co=
nsistent. regardless of ordering, optimization techniques such as CSE can b=
e applied in contexts where common subexpression doesn&#39;t have any side-=
effects.OOE can be applied when side-effects of code sequences are proven t=
o be uncorrelated...</div></div></blockquote><div><br></div></span><div>Fre=
e order of evaluation is the most natural way for the programmer to communi=
cate to the implementation that side effects are absent or can be assumed t=
o be uncorrelated;</div></div></div></div></blockquote><div style=3D"direct=
ion:ltr"><br></div><div style=3D"direction:ltr"><div style=3D"font-family:&=
#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8BWhat is the role=
 of the programmer=E2=80=8B here? how many trained programmers (I don&#39;t=
 even think of the novice) use the =C2=A0dirty syntax of putting every para=
meter in a reference/variable? Is this not lack of expressiveness?</div><di=
v style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">I=
n a language that even inlining is managed by the optimizer and programmers=
 code is a weak hint, such reasoning does not have any firm basis.</div></d=
iv></div></div></div></blockquote><div><br></div><div>Calculating arguments=
 individually (I assume this is what you mean) seems perfectly expressive t=
o me if it is the programmer&#39;s intent to serialize their side effects.<=
br></div><div>=C2=A0=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"=
rtl"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;bo=
rder-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex=
;padding-right:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div> this means that there is no need for the compiler to=
 prove anything, which may be difficult or impossible in the general case. =
In the (limited) instances where the programmer desires a specific ordering=
 of side effects, the language already provides (multiple) ways to explicit=
ly order evaluation.</div></div></div></div></blockquote><div style=3D"dire=
ction:ltr"><br></div><div style=3D"direction:ltr"><div style=3D"font-family=
:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8Bdiscovering si=
de effects involves the analysis of code in which the machine is more elega=
nt than man. If dependency check and removal of unreferenced functions/obje=
cts is possible, discovering side effects=E2=80=8B is possible too and guid=
elines do not too complex.=C2=A0</div></div></div></div></div></blockquote>=
<div><br></div><div>Not always, and that still doesn&#39;t answer the quest=
ion of to what extent side effects need to be serialized. As it is, unspeci=
fied order of evaluation is our best tool to express that.</div><div>=C2=A0=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"rtl"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb=
(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><spa=
n><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div dir=3D"rtl"><div style=3D"font-family:&#39;arial na=
rrow&#39;,sans-serif;font-size:large" dir=3D"ltr">What I am asking for, is =
a strong reason for rejecting a well-organized ordering scheme. I am really=
 curious to know why I should not expect the following line:</div><div styl=
e=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"=
ltr"><br></div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;=
font-size:large" dir=3D"ltr">cout &lt;&lt; (x=3D0) &lt;&lt; &quot;,&quot; &=
lt;&lt; ++x &lt;&lt; endl;</div><div style=3D"font-family:&#39;arial narrow=
&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div style=3D"font-=
family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">produ=
ce:</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-s=
ize:large" dir=3D"ltr"><br></div><div style=3D"font-family:&#39;arial narro=
w&#39;,sans-serif;font-size:large" dir=3D"ltr">0,1</div></div></blockquote>=
<div><br></div></span><div>That code is unproblematic, aside from the fact =
that it is trying to do far too many things in a single expression.</div></=
div></div></div></blockquote><div style=3D"direction:ltr"><br></div><div st=
yle=3D"direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans=
-serif;font-size:large">=E2=80=8BThat is exactly the point of this discussi=
on. Those are the problems needed to be removed. But they reside in the com=
piler and the std, rather than the=E2=80=8B code. It is hard to teach and t=
akes a lot of experience to learn;That is one reason many fear to face C++.=
</div></div></div></div></div></blockquote><div><br></div><div>Even if orde=
r of execution was defined for that snippet, it would still be bad style.</=
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"rtl"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;border-right-width:1px;border-right-=
color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-ri=
ght:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><div> Problems arise when, for example, we introduce aliasing:</div><d=
iv><br></div><div><div style=3D"font-family:&#39;arial narrow&#39;,sans-ser=
if;font-size:large;display:inline">=E2=80=8B=E2=80=8B</div>y =3D 1;</div><d=
iv>std::cout &lt;&lt; (x =3D 0) &lt;&lt; &quot;,&quot; &lt;&lt; ++y &lt;&lt=
; &#39;\n&#39;;</div><div><br></div></div></div></div></blockquote><div sty=
le=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><div style=3D"f=
ont-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8Bassu=
ming:</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font=
-size:large"><br></div><div style=3D"font-family:&#39;arial narrow&#39;,san=
s-serif;font-size:large">auto&amp; y=3Dx;</div><div style=3D"font-family:&#=
39;arial narrow&#39;,sans-serif;font-size:large"><div style=3D"font-family:=
arial,sans-serif;font-size:small"><div style=3D"font-family:&#39;arial narr=
ow&#39;,sans-serif;font-size:large;display:inline">=E2=80=8B</div>y =3D 1;<=
/div><div style=3D"font-family:arial,sans-serif;font-size:small">std::cout =
&lt;&lt; (x =3D 0) &lt;&lt; &quot;,&quot; &lt;&lt; ++y &lt;&lt; &#39;\n&#39=
;;</div></div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large"><br></div><div style=3D"font-family:&#39;arial narrow&#39;,=
sans-serif;font-size:large">the problem is not in the last line, it is the =
ill form of the program which is -IMHO- OT here.</div></div></div></div></d=
iv></blockquote><div><br></div><div>=C2=A0I am not assuming that y aliases =
x. The problem arises when the compiler cannot prove that x and y do not al=
ias.</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"rtl"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-ri=
ght-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;paddin=
g-right:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><div></div><div>It is unreasonable to expect the implementation to=
 produce &quot;0,2&quot; in the case where x and y do not alias but &quot;0=
,1&quot; in the case where they do.</div></div></div></div><span></span></b=
lockquote><div style=3D"direction:ltr"><br></div><div style=3D"direction:lt=
r"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:la=
rge">=E2=80=8Bagreed. but this is not the problem of evaluation order, it i=
s bad coding practice.=E2=80=8B</div></div></div></div></div></blockquote><=
/div><br></div><div class=3D"gmail_extra">What&#39;s bad about that code? H=
ow is it any worse than your snippet?</div></div>

<p></p>

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

--047d7bd7585afee667052db2e82d--

.

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

On Thu, Mar 10, 2016 at 1:04 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> Can you illustrate some ways to guarantee the implementations only using
> as-if rules behave as efficient as any possible implementations with aid of
> unsequenced evaluation rules?
>

No.  I'm sure there are programs which will become slower.  I don't care.
Statements
are sequenced, and we rely on compilers to optimize when they can, and we
live quite
comfortably with that.  I just don't find the "but optimization!" arguments
compelling.
Better language design is better even if it has costs.  That's why we don't
program in
assembler.

Specifying order of evaluation increases expressiveness because it makes
>> programs legal that are now illegal.
>>
>
> It does not make programs illegal because every weill-formed and
> well-defined programs will still be the same. Only already broken programs
> are effected. To expose such programs has nothing to do with being legal or
> not. Current implementations are allowed to do such things.
>

There are programs which are illegal under the current rules which become
legal under
defined order of evaluation rules.

    int category = 0;
  std::cout << ++category << " Those that belong to the emperor\n"
            << ++category << " Embalmed ones\n"
            // ...
            << ++category << " Those that, at a distance, resemble flies\n";

And on point, how many people would look at this example and realize that
it is in fact
illegal under current rules?


> On the contrast, it decreases expressiveness *of the language* because it
> makes the allowed set of properties of the source program strictly less
> than before.
>
>
>> The combination of confidence and ignorance accrues to those people who
>> insist that the evil consequences of failing to specify order of evaluation
>> can be mitigated by exhortation and review.
>> Specifying order of evaluation does not take away anyone's freedom.
>>
>
> Specifying order has taken away the freedom about assuming well-defined
> and safe reordering based on unsequenced evaluations, which including
> refactoring currently correct code without inspecting the whole
> implementation details of subexpressions for humans, and optimizing without
> relying on the as-if rule for compilers.
>

The freedom of compilers is unimportant.  Compilers must already follow
thousands of nitpicky
rules which constrain what they do.  Your argument about decreasing
expressiveness of the
language is wrong; were you correct, a language standard that said that all
programs have
undefined behavior and the standard imposes no requirements on them would
have the maximum
possible expressiveness.  But such a language would be useless, and no one
(except perhaps
possibly you) would declare such a language "expressive".

On the contrary, specifying order of evaluation increases expressiveness
because "expressiveness"
is the property of assigning meaning to writing, and specifying order adds
meaning in a context where
the order in which things happen is manifestly important.

--
You received this message because you are 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/CAHSYqdZkxSxUVWBnU5J%3DC4rUpVUmaRa5KCuCvEc3Njnogq4H9g%40mail.gmail.com.

--001a11440176e898a5052db3c8c6
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, Mar 10, 2016 at 1:04 AM, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&gt=
;</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>Can you=
 illustrate some ways to guarantee the implementations only using as-if rul=
es behave as efficient as any possible implementations with aid of unsequen=
ced evaluation rules?<br></div></div></blockquote><div><br></div><div>No.=
=C2=A0 I&#39;m sure there are programs which will become slower.=C2=A0 I do=
n&#39;t care.=C2=A0 Statements<br>are sequenced, and we rely on compilers t=
o optimize when they=C2=A0can, and we live quite<br>comfortably with that.=
=C2=A0 I just don&#39;t find the &quot;but optimization!&quot; arguments co=
mpelling.<br>Better language=C2=A0design is better even if it has costs.=C2=
=A0 That&#39;s why we don&#39;t program in<br>assembler.</div><div><br></di=
v><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""><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"><div><div class=3D"gmail_q=
uote"><div>Specifying order of evaluation increases expressiveness because =
it makes programs legal that are now illegal.<br></div></div></div></div></=
blockquote></span><div><br>It does not make programs illegal because every =
weill-formed and well-defined programs will still be the same. Only already=
 broken programs are effected. To expose such programs has nothing to do wi=
th being legal or not. Current implementations are allowed to do such thing=
s.<br></div></div></blockquote><div><br>There are programs which are illega=
l under the current rules which become legal under<br>defined order of eval=
uation rules.<br><br>=C2=A0 =C2=A0 <font face=3D"monospace, monospace">int =
category =3D 0;<br>=C2=A0 std::cout &lt;&lt; ++category &lt;&lt; &quot; Tho=
se that belong to the emperor\n&quot;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 &lt;&lt; ++category &lt;&lt; &quot; Embalmed ones\n&quot;</font></d=
iv><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // ...</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;&lt; ++category &lt;&lt; &quot; =
Those that, at a distance, resemble flies\n&quot;</font><span style=3D"font=
-family:monospace,monospace">;</span></div><div><br>And on point, how many =
people would look at this example and realize that it is in fact<br>illegal=
 under current rules?<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><br>On the contrast, it decreases expressiveness <i>of the la=
nguage</i> because it makes the allowed set of properties of the source pro=
gram strictly less than before.<br>=C2=A0<br></div><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>The combination of confidence and ignorance accrues to those pe=
ople who insist that the evil consequences of failing to specify order of e=
valuation can be mitigated by exhortation and review.<br>Specifying order o=
f evaluation does not take away anyone&#39;s freedom.</div></div></div></di=
v></blockquote><div>=C2=A0</div></span><div>Specifying order has taken away=
 the freedom about assuming well-defined and safe reordering based on unseq=
uenced evaluations, which including refactoring currently correct code with=
out inspecting the whole implementation details of subexpressions for human=
s, and optimizing without relying on the as-if rule for compilers.</div></d=
iv></blockquote><div><br>The freedom of compilers is unimportant.=C2=A0 Com=
pilers must already follow thousands of nitpicky<br>rules which constrain w=
hat they do.=C2=A0 Your argument about decreasing expressiveness of=C2=A0th=
e</div><div>language is wrong; were you correct, a language standard that s=
aid that all programs have<br>undefined behavior and the standard imposes n=
o requirements on them would have the maximum<br>possible expressiveness.=
=C2=A0 But such a language would be useless, and no one (except perhaps<br>=
possibly you) would declare such a language &quot;expressive&quot;.<br><br>=
On the contrary, specifying order of evaluation increases expressiveness be=
cause &quot;expressiveness&quot;<br>is the property of assigning meaning to=
 writing, and specifying order adds meaning in a context where<br>the order=
 in which things happen is manifestly important.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZkxSxUVWBnU5J%3DC4rUpVUmaRa5KC=
uCvEc3Njnogq4H9g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZkxSxUVW=
BnU5J%3DC4rUpVUmaRa5KCuCvEc3Njnogq4H9g%40mail.gmail.com</a>.<br />

--001a11440176e898a5052db3c8c6--

.

On 2016-03-10 10:50, Hyman Rosen wrote:
> There are programs which are illegal under the current rules which become
> legal under defined order of evaluation rules.
>
>   int category = 0;
>   std::cout << ++category << " Those that belong to the emperor\n"
>             << ++category << " Embalmed ones\n"
>             // ...
>             << ++category << " Those that, at a distance, resemble flies\n";

In what manner is that ill-formed? Please cite the relevant standardese.

--
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/nbs626%24vg3%241%40ger.gmane.org.

.

On 10 March 2016 at 18:06, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2016-03-10 10:50, Hyman Rosen wrote:
>> There are programs which are illegal under the current rules which become
>> legal under defined order of evaluation rules.
>>
>>   int category = 0;
>>   std::cout << ++category << " Those that belong to the emperor\n"
>>             << ++category << " Embalmed ones\n"
>>             // ...
>>             << ++category << " Those that, at a distance, resemble flies\n";
>
> In what manner is that ill-formed? Please cite the relevant standardese.


Well, no wonder this discussion isn't going anywhere. That code is not
ill-formed, but it has
undefined behavior, whereas it will have defined behavior if
evaluation order becomes
specified.

--
You received this message because you are 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/CAFk2RUZr9RHE7eUO3D%2Bcpr2ygOfCxV_QreTcfOzOBnRXExPMQw%40mail.gmail.com.

.

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

On Thu, Mar 10, 2016 at 11:06 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
>
> In what manner is that ill-formed? Please cite the relevant standardese.


1.9 { Program execution }
*If a side effect on a scalar object is unsequenced relative to either
another side effect on the same scalar object or a value computation using
the value of the same scalar object ... the behavior is undefined.*

This statement contains multiple side effects (the ++category expressions)
that are
unsequenced with respect to each other.  That you are participating in this
discussion
and didn't realize this demonstrates my point; even experts, even people
specifically
involved in a discussion of order of evaluation, fail to see when code
violates the rules.

What's the correct response?  Well, I could laugh at you, call you
incompetent, and
declare that I would never hire a simpleton such as yourself, and that of
course the
people I do hire would never make such a mistake.  Or I could get rid of
this ridiculous
problem by changing the language so that the statement does exactly what
every
reader of it assumes it does.  I find it so strange that there are people
who find the
former option appealing.

--
You received this message because you are 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/CAHSYqdY5J2gS8-TFEGibBX0fAR7xHPedX%2BgrrWmw7zy7MYWW4Q%40mail.gmail.com.

--001a114783cc1f3be8052db4324b
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, Mar 10, 2016 at 11:06 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> 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)=
;border-left-style:solid;padding-left:1ex">In what manner is that ill-forme=
d? Please cite the relevant standardese.</blockquote><div><br></div>1.9 { P=
rogram execution }<div><i>If a side effect on a scalar object is unsequence=
d relative to either another side effect on the same scalar object or a val=
ue computation using the value of the same scalar object ... the behavior i=
s undefined.</i></div><div><i><br></i></div><div>This statement contains mu=
ltiple side effects (the ++category expressions) that are<br>unsequenced wi=
th respect to each other.=C2=A0 That you are participating in this discussi=
on<br>and didn&#39;t realize this demonstrates my point; even experts, even=
 people specifically<br>involved in a discussion of order of evaluation, fa=
il to see when code violates the rules.<br><br>What&#39;s the correct respo=
nse?=C2=A0 Well, I could laugh at you, call you incompetent, and<br>declare=
 that I would never hire a simpleton such as yourself, and that of course t=
he<br>people I do hire would never make such a mistake.=C2=A0 Or I could ge=
t rid of this ridiculous<br>problem by changing the language so that the st=
atement does exactly what every<br>reader of it assumes it does.=C2=A0 I fi=
nd it so strange that there are people who find the<br>former option appeal=
ing.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY5J2gS8-TFEGibBX0fAR7xHPedX%2B=
grrWmw7zy7MYWW4Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY5J2gS8-=
TFEGibBX0fAR7xHPedX%2BgrrWmw7zy7MYWW4Q%40mail.gmail.com</a>.<br />

--001a114783cc1f3be8052db4324b--

.

On 2016-03-10 11:20, Hyman Rosen wrote:
> On Thu, Mar 10, 2016 at 11:06 AM, Matthew Woehlke wrote:
>> In what manner is that ill-formed? Please cite the relevant standardese.
>
> 1.9 { Program execution }
> *If a side effect on a scalar object is unsequenced relative to either
> another side effect on the same scalar object or a value computation using
> the value of the same scalar object ... the behavior is undefined.*

Thanks.

> What's the correct response?  Well, I could laugh at you, call you
> incompetent, and declare that I would never hire a simpleton such as
> yourself, and that of course the people I do hire would never make
> such a mistake.

I wouldn't write that code either. I think you miss the point I was
trying to make; it isn't that we don't all look at that code and agree
it's ugly / troublesome / whatever, it's that your side is throwing
around emotionally charged words like "illegal" without substantiation.

*THANK YOU* for actually backing up your claim. That's something that
isn't happening nearly enough here, and is exactly what I've been trying
to address.

Incidentally, both GCC and clang warn about that code...

Oh, and... GCC (since at least 4.4.7, even!) *does* also collapse all
the increment operations into a single addition, so this is also a
counterexample to the claim that no existing compilers leverage
unspecified order to optimize :-).

--
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/nbs8ut%24igr%241%40ger.gmane.org.

.

On 03/10/2016 05:55 PM, Matthew Woehlke wrote:
> On 2016-03-10 11:20, Hyman Rosen wrote:
>> On Thu, Mar 10, 2016 at 11:06 AM, Matthew Woehlke wrote:
>>> In what manner is that ill-formed? Please cite the relevant standardese.
>>
>> 1.9 { Program execution }
>> *If a side effect on a scalar object is unsequenced relative to either
>> another side effect on the same scalar object or a value computation using
>> the value of the same scalar object ... the behavior is undefined.*

Note that "ill-formed" and "undefined behavior" are different.

"ill-formed" things are required to give you a diagnostic at
compile-time, whereas "undefined behavior" doesn't.

When talking about order-of-evaluation, the issue is usually
"undefined behavior" in certain circumstances.

Jens

--
You received this message because you are 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/56E1A8C8.4080003%40gmx.net.

.

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

On Thu, Mar 10, 2016 at 12:03 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
>
> Note that "ill-formed" and "undefined behavior" are different.


I used the word "illegal", which ought to cover both.

On Thu, Mar 10, 2016 at 11:55 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:
>
> Oh, and... GCC (since at least 4.4.7, even!) *does* also collapse all
> the increment operations into a single addition, so this is also a
> counterexample to the claim that no existing compilers leverage
> unspecified order to optimize :-).


This expression has undefined behavior, so the compiler may choose
to do anything at all.

--
You received this message because you are 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/CAHSYqdYRNKv-tNYgO-0kJhmhHa%2BPDjvYaJraJh5WkgkTstJhvw%40mail.gmail.com.

--001a1143f154a94fed052db5006c
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, Mar 10, 2016 at 12:03 PM, Jens Maurer <span dir=3D"ltr">&lt;<a href=3D"=
mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.net</a>&gt;</=
span> 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);border-left-s=
tyle:solid;padding-left:1ex">Note that &quot;ill-formed&quot; and &quot;und=
efined behavior&quot; are different.</blockquote><div><br>I used the word &=
quot;illegal&quot;, which ought to cover both.</div><div><br></div><div>On =
Thu, Mar 10, 2016 at 11:55 AM, Matthew Woehlke=C2=A0<span dir=3D"ltr">&lt;<=
a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss=
@gmail.com</a>&gt;</span>=C2=A0wrote:<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">Oh, and... GCC (since=
 at least 4.4.7, even!) *does* also collapse all<br>the increment operation=
s into a single addition, so this is also a<br>counterexample to the claim =
that no existing compilers leverage<br>unspecified order to optimize :-).</=
blockquote><div><br>This expression has undefined behavior, so the compiler=
 may choose<br>to do anything at all.=C2=A0</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYRNKv-tNYgO-0kJhmhHa%2BPDjvYaJ=
raJh5WkgkTstJhvw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYRNKv-tN=
YgO-0kJhmhHa%2BPDjvYaJraJh5WkgkTstJhvw%40mail.gmail.com</a>.<br />

--001a1143f154a94fed052db5006c--

.

--047d7b5d4a2630e587052db50f8e
Content-Type: text/plain; charset=UTF-8

> > If the compiler can't optimize effectively because the side-effects of
> the subexpressions are unknown, then it seems unlikely that significant
> optimization was going to happen anyways.
> What is the justification for this assertion? CSE, for example, can be
> applied even when its result is passed to an opaque function.


My assertion is a matter of personal expectations. If I am calling
functions whose definitions are not visible I do not expect the compiler to
do a good job of optimizing my code. I'm not saying that all optimizations
are off the table, but that the optimizer is significantly hampered and
expectations should be set accordingly.

Given the extent of these discussions, it seems likely that if we do
specify evaluation order, compilers will provide an option / migration path
for users relying on old behavior. If there is real value to be had there
then I would expect compiler vendors to provide a variety of nonstandard
options for the discerning customer. The fact that this might happen
wouldn't be evidence that we made a bad decision. Vendors provide all sorts
of nonstandard extensions to fulfill obscure scenarios or platform-specific
optimizations. It would be nice to have a trustworthy common baseline that
can be relied on.



> Besides, the issue is not whether the behavior is unspecified, it is
> whether it cannot be proven not to be unspecified. We have already covered
> opaque functions that the type system does not allow us to assert do not
> modify memory accessed elsewhere in the expression; similarly, one can have
> pointers that cannot be proved not to alias:
> int g(int* p) { return *p = 0; }
> int h(int* q) { return *q; }
> int f(int* p, int* q) { return g(p) + h(q); }
> With free ordering the write to *p and read from *q can execute in
> parallel; under strict ordering the compiler must order the read after the
> write, or must test p against q.


Right, this is why I think we should refocus our discussion on semantics.
What do we *want *this code to mean? Should it mean "read the manual for
each compiler you are currently using" or should it have a well-defined
meaning?


> Though the syntax is handy, you can imagine that expressions like this
> are really dangerous for any side-effects they might have. Code like this
> definitely wants an evaluation order.
> I don't see anything there that would care what order the subexpressions
> are evaluated in. Am I missing something?
> > There's a fair argument that this code shouldn't be written like this in
> C++ today, but there's also a fair argument that this is a useful way of
> writing some things and maybe we should think about making code like this
> less dangerous. At least in our case, this is also code where performance
> is of effectively 0 concern since it is dead cold.
> That looks to me like an initialization, so it should be possible to write
> using list-initialization syntax. It might be too late for that particular
> API, but a wrapper API or next version should be able to manage it.


I was attempting to provide a simplified version but I think I did a
disservice in the process. The actual system is quite a bit more
complicated.

Here's some documentation on that UI framework, the bottom of the page
starts giving you some idea of how it is designed to build large UI
hierarchies as one big expression. It's very easy to have an order of
evaluation issue, as you are no longer thinking in terms of expressions,
but in terms of simply declaring nested objects. This is really an  EDSL.
In short, this framework builds up an entire UI hierarchy typically as a
single expression. The examples listed here are relatively simple, but when
two widgets is a 30 line expression, an actually useful UI may be a
several-hundred-line expression. There's no way someone can evaluate each
subexpression for conflicting side-effects.

https://docs.unrealengine.com/latest/INT/Programming/Slate/Widgets/index.html

And again it's easy to argue that maybe code like this shouldn't be
written, but clearly it is very useful. We're hampering the expressivity of
EDSLs if we say that writing code like this will forever be bad style
because we refuse to guarantee an evaluation order. List initialization
can't be used because this framework relies on shared_from_this which
cannot be used in a constructor. To support that it relies on two-phase
initialization, which is hidden by the tricks of the EDSL.



On Wed, Mar 9, 2016 at 12:55 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

>
> On 8 Mar 2016 23:06, "Brent Friedman" <fourthgeek@gmail.com> wrote:
> >>
> >> A couple of possibilities: CSE, register pressure, instruction timing.
> Pretty much any non-peephole optimization can benefit from free ordering of
> evaluating subexpressions.
> >
> >
> > Under the as-if rule, the compiler is free to optimize as it wants. Just
> because we specify an evaluation order doesn't mean the machine
> instructions have to be emitted in a particular order.
>
> Can we please take it as read that we are discussing optimizations that
> are not available under the as if rule?
>
> > If the compiler can't optimize effectively because the side-effects of
> the subexpressions are unknown, then it seems unlikely that significant
> optimization was going to happen anyways.
>
> What is the justification for this assertion? CSE, for example, can be
> applied even when its result is passed to an opaque function.
>
> > If the compiler can't optimize as effectively because there are multiple
> side-effects which it was previously reordering optimally but can no longer
> reorder optimally, then that seems like a potentially legitimate (if rare)
> scenario for concern. However, in that scenario, the semantics of the code
> were probably undefined anyways since OOE was undefined.
>
> Unspecified, not undefined. There is a huge difference.
>
> Besides, the issue is not whether the behavior is unspecified, it is
> whether it cannot be proven not to be unspecified. We have already covered
> opaque functions that the type system does not allow us to assert do not
> modify memory accessed elsewhere in the expression; similarly, one can have
> pointers that cannot be proved not to alias:
>
> int g(int* p) { return *p = 0; }
> int h(int* q) { return *q; }
> int f(int* p, int* q) { return g(p) + h(q); }
>
> With free ordering the write to *p and read from *q can execute in
> parallel; under strict ordering the compiler must order the read after the
> write, or must test p against q.
>
> > I think we should focus on getting the right semantics.
> >
> > We have some code which uses a style like this for declaring UI elements:
> >
> >> new Window().add(
> >>    new BorderElement(3_px).add(
> >>       new Scroller().add( new TextBox("Hello"), new Image("chat.png")
>  ),
> >>       new Hyperlink("help.html")
> >>     ) );
> >
> >
> > Though the syntax is handy, you can imagine that expressions like this
> are really dangerous for any side-effects they might have. Code like this
> definitely wants an evaluation order.
>
> I don't see anything there that would care what order the subexpressions
> are evaluated in. Am I missing something?
>
> > There's a fair argument that this code shouldn't be written like this in
> C++ today, but there's also a fair argument that this is a useful way of
> writing some things and maybe we should think about making code like this
> less dangerous. At least in our case, this is also code where performance
> is of effectively 0 concern since it is dead cold.
>
> That looks to me like an initialization, so it should be possible to write
> using list-initialization syntax. It might be too late for that particular
> API, but a wrapper API or next version should be able to manage 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/CAJnLdObzpNT2%2BVVEKU%2BwzaMms_2Jz3uHezuFEA-G3ZuqCCGrvQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObzpNT2%2BVVEKU%2BwzaMms_2Jz3uHezuFEA-G3ZuqCCGrvQ%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/CADbh%2BeTvCVSA%3DhTx-aPEZUL49grCvytEdRXS4_ePL1OPznYyzA%40mail.gmail.com.

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

<div dir=3D"ltr"><div><br></div><div><blockquote class=3D"gmail_quote" styl=
e=3D"color:rgb(80,0,80);font-size:12.8px;margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex">&gt; If the compiler can&#39;t optimize effectively because =
the side-effects of the subexpressions are unknown, then it seems unlikely =
that significant optimization was going to happen anyways.<br>What is the j=
ustification for this assertion? CSE, for example, can be applied even when=
 its result is passed to an opaque function.</blockquote><div style=3D"colo=
r:rgb(80,0,80);font-size:12.8px"><br></div><div style=3D"color:rgb(80,0,80)=
;font-size:12.8px">My assertion is a matter of personal expectations. If I =
am calling functions whose definitions are not visible I do not expect the =
compiler to do a good job of optimizing my code. I&#39;m not saying that al=
l optimizations are off the table, but that the optimizer is significantly =
hampered and expectations should be set accordingly.</div><div style=3D"col=
or:rgb(80,0,80);font-size:12.8px"><br></div><div style=3D"color:rgb(80,0,80=
);font-size:12.8px">Given the extent of these discussions, it seems likely =
that if we do specify evaluation order, compilers will provide an option / =
migration path for users relying on old behavior. If there is real value to=
 be had there then I would expect compiler vendors to provide a variety of =
nonstandard options for the discerning customer. The fact that this might h=
appen wouldn&#39;t be evidence that we made a bad decision. Vendors provide=
 all sorts of nonstandard extensions to fulfill obscure scenarios or platfo=
rm-specific optimizations. It would be nice to have a trustworthy common ba=
seline that can be relied on.</div></div><div style=3D"color:rgb(80,0,80);f=
ont-size:12.8px"><br></div><div>=C2=A0</div><blockquote 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" class=3D"gmail_quote">Besides, the i=
ssue is not whether the behavior is unspecified, it is whether it cannot be=
 proven not to be unspecified. We have already covered opaque functions tha=
t the type system does not allow us to assert do not modify memory accessed=
 elsewhere in the expression; similarly, one can have pointers that cannot =
be proved not to alias:<br>int g(int* p) { return *p =3D 0; }<br>int h(int*=
 q) { return *q; }<br>int f(int* p, int* q) { return g(p) + h(q); }<br><spa=
n style=3D"font-size:12.8px">With free ordering the write to *p and read fr=
om *q can execute in parallel; under strict ordering the compiler must orde=
r the read after the write, or must test p against q.</span></blockquote><d=
iv><br></div><div>Right, this is why I think we should refocus our discussi=
on on semantics. What do we <i>want </i>this code to mean? Should it mean &=
quot;read the manual for each compiler you are currently using&quot; or sho=
uld it have a well-defined meaning?</div><div>=C2=A0</div><div><br></div><d=
iv><span class=3D"im" style=3D"font-size:12.8px"><blockquote 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" class=3D"gmail_quote">&gt; Thou=
gh the syntax is handy, you can imagine that expressions like this are real=
ly dangerous for any side-effects they might have. Code like this definitel=
y wants an evaluation order.<br>I don&#39;t see anything there that would c=
are what order the subexpressions are evaluated in. Am I missing something?=
<br>&gt; There&#39;s a fair argument that this code shouldn&#39;t be writte=
n like this in C++ today, but there&#39;s also a fair argument that this is=
 a useful way of writing some things and maybe we should think about making=
 code like this less dangerous. At least in our case, this is also code whe=
re performance is of effectively 0 concern since it is dead cold.<br>That l=
ooks to me like an initialization, so it should be possible to write using =
list-initialization syntax. It might be too late for that particular API, b=
ut a wrapper API or next version should be able to manage it.</blockquote><=
div>=C2=A0</div></span></div><div>I was attempting to provide a simplified =
version but I think I did a disservice in the process. The actual system is=
 quite a bit more complicated.</div><div><br></div><div>Here&#39;s some doc=
umentation on that UI framework, the bottom of the page starts giving you s=
ome idea of how it is designed to build large UI hierarchies as one big exp=
ression. It&#39;s very easy to have an order of evaluation issue, as you ar=
e no longer thinking in terms of expressions, but in terms of simply declar=
ing nested objects. This is really an =C2=A0EDSL. In short, this framework =
builds up an entire UI hierarchy typically as a single expression. The exam=
ples listed here are relatively simple, but when two widgets is a 30 line e=
xpression, an actually useful UI may be a several-hundred-line expression. =
There&#39;s no way someone can evaluate each subexpression for conflicting =
side-effects.</div><div><br></div><div><a href=3D"https://docs.unrealengine=
..com/latest/INT/Programming/Slate/Widgets/index.html" target=3D"_blank">htt=
ps://docs.unrealengine.com/latest/INT/Programming/Slate/Widgets/index.html<=
/a></div><div><br></div><div>And again it&#39;s easy to argue that maybe co=
de like this shouldn&#39;t be written, but clearly it is very useful. We&#3=
9;re hampering the expressivity of EDSLs if we say that writing code like t=
his will forever be bad style because we refuse to guarantee an evaluation =
order. List initialization can&#39;t be used because this framework relies =
on shared_from_this which cannot be used in a constructor. To support that =
it relies on two-phase initialization, which is hidden by the tricks of the=
 EDSL.</div><div><br></div><div><br></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Wed, Mar 9, 2016 at 12:55 AM, &#39;Edward=
 Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;=
<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals=
@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D""><p dir=3D"ltr"><br>
On 8 Mar 2016 23:06, &quot;Brent Friedman&quot; &lt;<a href=3D"mailto:fourt=
hgeek@gmail.com" target=3D"_blank">fourthgeek@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; A couple of possibilities: CSE, register pressure, instruction tim=
ing. Pretty much any non-peephole optimization can benefit from free orderi=
ng of evaluating subexpressions.<br>
&gt;<br>
&gt;<br>
&gt; Under the as-if rule, the compiler is free to optimize as it wants. Ju=
st because we specify an evaluation order doesn&#39;t mean the machine inst=
ructions have to be emitted in a particular order.</p>
</span><p dir=3D"ltr">Can we please take it as read that we are discussing =
optimizations that are not available under the as if rule? </p><span class=
=3D"">
<p dir=3D"ltr">&gt; If the compiler can&#39;t optimize effectively because =
the side-effects of the subexpressions are unknown, then it seems unlikely =
that significant optimization was going to happen anyways.</p>
</span><p dir=3D"ltr">What is the justification for this assertion? CSE, fo=
r example, can be applied even when its result is passed to an opaque funct=
ion.</p><span class=3D"">
<p dir=3D"ltr">&gt; If the compiler can&#39;t optimize as effectively becau=
se there are multiple side-effects which it was previously reordering optim=
ally but can no longer reorder optimally, then that seems like a potentiall=
y legitimate (if rare) scenario for concern. However, in that scenario, the=
 semantics of the code were probably undefined anyways since OOE was undefi=
ned.</p>
</span><p dir=3D"ltr">Unspecified, not undefined. There is a huge differenc=
e. </p>
<p dir=3D"ltr">Besides, the issue is not whether the behavior is unspecifie=
d, it is whether it cannot be proven not to be unspecified. We have already=
 covered opaque functions that the type system does not allow us to assert =
do not modify memory accessed elsewhere in the expression; similarly, one c=
an have pointers that cannot be proved not to alias:</p>
<p dir=3D"ltr">int g(int* p) { return *p =3D 0; }<br>
int h(int* q) { return *q; }<br>
int f(int* p, int* q) { return g(p) + h(q); }</p>
<p dir=3D"ltr">With free ordering the write to *p and read from *q can exec=
ute in parallel; under strict ordering the compiler must order the read aft=
er the write, or must test p against q.</p><span class=3D"">
<p dir=3D"ltr">&gt; I think we should focus on getting the right semantics.=
<br>
&gt;<br>
&gt; We have some code which uses a style like this for declaring UI elemen=
ts:<br>
&gt;<br>
&gt;&gt; new Window().add(=C2=A0<br>
&gt;&gt; =C2=A0 =C2=A0new BorderElement(3_px).add(<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0 new Scroller().add( new TextBox(&quot;Hello&q=
uot;), new Image(&quot;chat.png&quot;) =C2=A0),<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0 new Hyperlink(&quot;help.html&quot;)<br>
&gt;&gt; =C2=A0 =C2=A0 ) );<br>
&gt;<br>
&gt;<br>
&gt; Though the syntax is handy, you can imagine that expressions like this=
 are really dangerous for any side-effects they might have. Code like this =
definitely wants an evaluation order.</p>
</span><p dir=3D"ltr">I don&#39;t see anything there that would care what o=
rder the subexpressions are evaluated in. Am I missing something? </p><span=
 class=3D"">
<p dir=3D"ltr">&gt; There&#39;s a fair argument that this code shouldn&#39;=
t be written like this in C++ today, but there&#39;s also a fair argument t=
hat this is a useful way of writing some things and maybe we should think a=
bout making code like this less dangerous. At least in our case, this is al=
so code where performance is of effectively 0 concern since it is dead cold=
..</p>
</span><p dir=3D"ltr">That looks to me like an initialization, so it should=
 be possible to write using list-initialization syntax. It might be too lat=
e for that particular API, but a wrapper API or next version should be able=
 to manage it. </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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/CAJnLdObzpNT2%2BVVEKU%2BwzaMms_2Jz3uH=
ezuFEA-G3ZuqCCGrvQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAJnLdObzpNT2%2BVVEKU%2BwzaMms_2Jz3uHezuFEA-G3ZuqCCGrvQ%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTvCVSA%3DhTx-aPEZUL49grCvytE=
dRXS4_ePL1OPznYyzA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeTvCV=
SA%3DhTx-aPEZUL49grCvytEdRXS4_ePL1OPznYyzA%40mail.gmail.com</a>.<br />

--047d7b5d4a2630e587052db50f8e--

.

------=_Part_1189_950753828.1457640713161
Content-Type: multipart/alternative;
 boundary="----=_Part_1190_1709535230.1457640713161"

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



Op donderdag 10 maart 2016 15:40:01 UTC+1 schreef Michi Henning:
>
> I=E2=80=99ve been following this discussion for weeks now. It has served =
as a=20
> sterling reminder of why I stopped working on CORBA=20
> <http://www.triodia.com/staff/michi/queue/riseAndFallOfCorba.pdf>.
>
> Too many cooks eternally spoil the broth.
>

Excellent point. Thanks again for your courage Michi!


Wil=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/eaa2760f-3b1b-4ec4-a38d-43c776de7875%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>Op donderdag 10 maart 2016 15:40:01 UTC+1 schreef =
Michi Henning:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wo=
rd-wrap:break-word"><div><div>I=E2=80=99ve been following this discussion f=
or weeks now. It has served as a sterling reminder of why=C2=A0<a href=3D"h=
ttp://www.triodia.com/staff/michi/queue/riseAndFallOfCorba.pdf" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.c=
om/url?q\75http%3A%2F%2Fwww.triodia.com%2Fstaff%2Fmichi%2Fqueue%2FriseAndFa=
llOfCorba.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNHgP2NjK7K6Rc9Z4wtLhfN2KR_Q=
PA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url=
?q\75http%3A%2F%2Fwww.triodia.com%2Fstaff%2Fmichi%2Fqueue%2FriseAndFallOfCo=
rba.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNHgP2NjK7K6Rc9Z4wtLhfN2KR_QPA&#39=
;;return true;">I stopped working on CORBA</a>.</div></div><div><br></div><=
div>Too many cooks eternally spoil the broth.</div></div></blockquote><div>=
<br>Excellent point. Thanks again for your courage Michi!<br><br><br>Wil <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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eaa2760f-3b1b-4ec4-a38d-43c776de7875%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eaa2760f-3b1b-4ec4-a38d-43c776de7875=
%40isocpp.org</a>.<br />

------=_Part_1190_1709535230.1457640713161--
------=_Part_1189_950753828.1457640713161--

.

------=_Part_1514_786718749.1457672574195
Content-Type: multipart/alternative;
 boundary="----=_Part_1515_2099821625.1457672574195"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=8811:51:18=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Mar 10, 2016 at 1:04 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>
> Can you illustrate some ways to guarantee the implementations only using=
=20
> as-if rules behave as efficient as any possible implementations with aid =
of=20
> unsequenced evaluation rules?
>
>
> No.  I'm sure there are programs which will become slower.  I don't care.
>

OK. *You* don't care. But for all users, care || (not care) =3D=3D care:)
=20

> Statements
> are sequenced, and we rely on compilers to optimize when they can, and we=
=20
> live quite
> comfortably with that.
>
That' still you.
I am comfortable with that for any single implementation, but I am not=20
comfortable with the language forcing you accepting "it is right". The best=
=20
word of such a "feature" is "compromise", to balance the expressiveness of=
=20
the language and the laziness/ignorance/carelessness of users. That=20
limitation is actually redundant in nature. It bloats the specification=20
without any benefit for users, at least for those who are not so lazy,=20
ignorant or careless. To be lazy, ignorant or careless is encouraged...=20
That's wrong.
=20

> I just don't find the "but optimization!" arguments compelling.
> Better language design is better even if it has costs.  That's why we=20
> don't program in
> assembler.
>
> The costs may lead to bad design. In this case it is bad, even with no=20
penalty on optimization. There can be abstraction reduce the costs.=20
Assembly languages actually go opposite, because they are without=20
sufficient constructs to mandate intended "unspecified" properties on the=
=20
programs to express "I don't care". To keep unspecified evaluation order=20
away is more likely a change towards a assembly language.
=20

> Specifying order of evaluation increases expressiveness because it makes=
=20
> programs legal that are now illegal.
>
>
> It does not make programs illegal because every weill-formed and=20
> well-defined programs will still be the same. Only already broken program=
s=20
> are effected. To expose such programs has nothing to do with being legal =
or=20
> not. Current implementations are allowed to do such things.
>
>
> There are programs which are illegal under the current rules which become=
=20
> legal under
> defined order of evaluation rules.
>
> I don't think it necessary.
=20

>     int category =3D 0;
>   std::cout << ++category << " Those that belong to the emperor\n"
>             << ++category << " Embalmed ones\n"
>             // ...
>             << ++category << " Those that, at a distance, resemble flies\=
n"
> ;
>
> And on point, how many people would look at this example and realize that=
=20
> it is in fact
> illegal under current rules?
>

More or less. Maybe you think too few.
But most people do not write such code at all. There is no reason to write=
=20
such code, due to the no-so-usable interface (cout) and bad style (mixed=20
multiple side effects on same object) used. Even with cout, why not ';'=20
instead of '<<' for each category? It is also not so friendly to be=20
generated by programs.
I will warn others to avoid writing such a mess, no matter the sequenced=20
rules exist or not.

=20
>

> On the contrast, it decreases expressiveness *of the language* because it=
=20
> makes the allowed set of properties of the source program strictly less=
=20
> than before.
> =20
>
> The combination of confidence and ignorance accrues to those people who=
=20
> insist that the evil consequences of failing to specify order of evaluati=
on=20
> can be mitigated by exhortation and review.
> Specifying order of evaluation does not take away anyone's freedom.
>
> =20
> Specifying order has taken away the freedom about assuming well-defined=
=20
> and safe reordering based on unsequenced evaluations, which including=20
> refactoring currently correct code without inspecting the whole=20
> implementation details of subexpressi
>
> ...

--=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/26a3a11f-6901-4142-b993-991c297428e0%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=8811:51:18=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>On Thu, Mar 10, 2016 at 1:04 AM, FrankHB1989 <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"6X4bOHXrBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">frank...@gmail.com</a>&gt;</span> wrote:<blockquote style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>Can you illustrate some ways to guarantee the implementations only u=
sing as-if rules behave as efficient as any possible implementations with a=
id of unsequenced evaluation rules?<br></div></div></blockquote><div><br></=
div><div>No.=C2=A0 I&#39;m sure there are programs which will become slower=
..=C2=A0 I don&#39;t care.</div></div></div></div></blockquote><div><br>OK. =
<i>You</i> don&#39;t care. But for all users, care || (not care) =3D=3D car=
e:)<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 di=
r=3D"ltr"><div><div><div>Statements<br>are sequenced, and we rely on compil=
ers to optimize when they=C2=A0can, and we live quite<br>comfortably with t=
hat.</div></div></div></div></blockquote><div>That&#39; still you.<br>I am =
comfortable with that for any single implementation, but I am not comfortab=
le with the language forcing you accepting &quot;it is right&quot;. The bes=
t word of such a &quot;feature&quot; is &quot;compromise&quot;, to balance =
the expressiveness of the language and the laziness/ignorance/carelessness =
of users. That limitation is actually redundant in nature. It bloats the sp=
ecification without any benefit for users, at least for those who are not s=
o lazy, ignorant or careless. To be lazy, ignorant or careless is encourage=
d... That&#39;s wrong.<br>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><div><div>I just don&#39;t find the &quot;but=
 optimization!&quot; arguments compelling.<br>Better language=C2=A0design i=
s better even if it has costs.=C2=A0 That&#39;s why we don&#39;t program in=
<br>assembler.</div><div><br></div></div></div></div></blockquote><div>The =
costs may lead to bad design. In this case it is bad, even with no penalty =
on optimization. There can be abstraction reduce the costs. Assembly langua=
ges actually go opposite, because they are without sufficient constructs to=
 mandate intended &quot;unspecified&quot; properties on the programs to exp=
ress &quot;I don&#39;t care&quot;. To keep unspecified evaluation order awa=
y is more likely a change towards a assembly language.<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><div=
></div><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><span><blockquote style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div><div><div>Specifying order of evaluation increases expressiveness becau=
se it makes programs legal that are now illegal.<br></div></div></div></div=
></blockquote></span><div><br>It does not make programs illegal because eve=
ry weill-formed and well-defined programs will still be the same. Only alre=
ady broken programs are effected. To expose such programs has nothing to do=
 with being legal or not. Current implementations are allowed to do such th=
ings.<br></div></div></blockquote><div><br>There are programs which are ill=
egal under the current rules which become legal under<br>defined order of e=
valuation rules.<br><br></div></div></div></div></blockquote><div>I don&#39=
;t think it necessary.<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>=C2=A0 =C2=A0 <font face=3D"mon=
ospace, monospace">int category =3D 0;<br>=C2=A0 std::cout &lt;&lt; ++categ=
ory &lt;&lt; &quot; Those that belong to the emperor\n&quot;<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;&lt; ++category &lt;&lt; &quot; Embalme=
d ones\n&quot;</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...</font></div><div><font face=3D"mo=
nospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;&lt; ++ca=
tegory &lt;&lt; &quot; Those that, at a distance, resemble flies\n&quot;</f=
ont><span style=3D"font-family:monospace,monospace">;</span></div><div><br>=
And on point, how many people would look at this example and realize that i=
t is in fact<br>illegal under current rules?<br></div></div></div></div></b=
lockquote><div><br>More or less. Maybe you think too few.<br>But most peopl=
e do not write such code at all. There is no reason to write such code, due=
 to the no-so-usable interface (cout) and bad style (mixed multiple side ef=
fects on same object) used. Even with cout, why not &#39;;&#39; instead of =
&#39;&lt;&lt;&#39; for each category? It is also not so friendly to be gene=
rated by programs.<br>I will warn others to avoid writing such a mess, no m=
atter the sequenced rules exist or not.<br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div>=C2=A0<br></div></di=
v></div></div></blockquote><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><div></div><blockquote style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>On th=
e contrast, it decreases expressiveness <i>of the language</i> because it m=
akes the allowed set of properties of the source program strictly less than=
 before.<br>=C2=A0<br></div><span><blockquote style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
div><div>The combination of confidence and ignorance accrues to those peopl=
e who insist that the evil consequences of failing to specify order of eval=
uation can be mitigated by exhortation and review.<br>Specifying order of e=
valuation does not take away anyone&#39;s freedom.</div></div></div></div><=
/blockquote><div>=C2=A0</div></span><div>Specifying order has taken away th=
e freedom about assuming well-defined and safe reordering based on unsequen=
ced evaluations, which including refactoring currently correct code without=
 inspecting the whole implementation details of subexpressi</div></div></bl=
ockquote></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/26a3a11f-6901-4142-b993-991c297428e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/26a3a11f-6901-4142-b993-991c297428e0=
%40isocpp.org</a>.<br />

------=_Part_1515_2099821625.1457672574195--
------=_Part_1514_786718749.1457672574195--

.

------=_Part_1512_855388200.1457673660258
Content-Type: multipart/alternative;
 boundary="----=_Part_1513_777941826.1457673660258"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=8811:51:18=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Mar 10, 2016 at 1:04 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>
>>
>> On the contrast, it decreases expressiveness *of the language* because=
=20
>> it makes the allowed set of properties of the source program strictly le=
ss=20
>> than before.
>> =20
>>
>>> The combination of confidence and ignorance accrues to those people who=
=20
>>> insist that the evil consequences of failing to specify order of evalua=
tion=20
>>> can be mitigated by exhortation and review.
>>> Specifying order of evaluation does not take away anyone's freedom.
>>>
>> =20
>> Specifying order has taken away the freedom about assuming well-defined=
=20
>> and safe reordering based on unsequenced evaluations, which including=20
>> refactoring currently correct code without inspecting the whole=20
>> implementation details of subexpressions for humans, and optimizing with=
out=20
>> relying on the as-if rule for compilers.
>>
>
> The freedom of compilers is unimportant.  Compilers must already follow=
=20
> thousands of nitpicky
> rules which constrain what they do.=20
>

OK, not only compilers, but also humans' brain. I clearly don't what to=20
"run" the program in my brain with a manner I don't want. If I am forced by=
=20
the language to do so, than I can select a modified dialect to replace it,=
=20
before I actually implement that dialect in a compiler. If such virtual=20
fork is encouraged, than the standard is quickly being not like a=20
"standard".
=20

> Your argument about decreasing expressiveness of the
> language is wrong; were you correct, a language standard that said that=
=20
> all programs have
> undefined behavior and the standard imposes no requirements on them would=
=20
> have the maximum
> possible expressiveness.  But such a language would be useless, and no on=
e=20
> (except perhaps
> possibly you) would declare such a language "expressive".
>
> That's red herring. Keeping unspecified evaluation order does not forbid=
=20
you specifying the order when needed, as I have said, just in a style that=
=20
you don't want. This is quite opposite to "all undefined", which actually=
=20
gives you *no expressiveness*. Another example is CWG1227=20
<http://wg21.cmeerw.net/cwg/issue1227>. The resolution is not good, but it=
=20
is somewhat acceptable as the compromise because we have no easy way to=20
express ordered substitution in such cases otherwise (without additional=20
complicated modification to the language).

=20

> On the contrary, specifying order of evaluation increases expressiveness=
=20
> because "expressiveness"
> is the property of assigning meaning to writing, and specifying order add=
s=20
> meaning in a context where
> the order in which things happen is manifestly important.
>

--=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/b0290aaa-9fcb-4394-9375-fc857f763071%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8810=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=8811:51:18=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, Mar 10, 2016 at 1:04 =
AM, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"6X4bOHXrBgAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#3=
9;javascript:&#39;;return true;">frank...@gmail.com</a>&gt;</span> wrote:<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"><div><br>On the contrast,=
 it decreases expressiveness <i>of the language</i> because it makes the al=
lowed set of properties of the source program strictly less than before.<br=
>=C2=A0<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><div class=3D"gmail_quote"><div>The combination of confidence and=
 ignorance accrues to those people who insist that the evil consequences of=
 failing to specify order of evaluation can be mitigated by exhortation and=
 review.<br>Specifying order of evaluation does not take away anyone&#39;s =
freedom.</div></div></div></div></blockquote><div>=C2=A0</div></span><div>S=
pecifying order has taken away the freedom about assuming well-defined and =
safe reordering based on unsequenced evaluations, which including refactori=
ng currently correct code without inspecting the whole implementation detai=
ls of subexpressions for humans, and optimizing without relying on the as-i=
f rule for compilers.</div></div></blockquote><div><br>The freedom of compi=
lers is unimportant.=C2=A0 Compilers must already follow thousands of nitpi=
cky<br>rules which constrain what they do. </div></div></div></div></blockq=
uote><div><br>OK, not only compilers, but also humans&#39; brain. I clearly=
 don&#39;t what to=20
&quot;run&quot; the program in my brain with a manner I don&#39;t want. If =
I am forced
 by the language to do so, than I can select a modified dialect to=20
replace it, before I actually implement that dialect in a compiler. If=20
such virtual fork is encouraged, than the standard is quickly being not=20
like a &quot;standard&quot;.<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Your ar=
gument about decreasing expressiveness of=C2=A0the</div><div>language is wr=
ong; were you correct, a language standard that said that all programs have=
<br>undefined behavior and the standard imposes no requirements on them wou=
ld have the maximum<br>possible expressiveness.=C2=A0 But such a language w=
ould be useless, and no one (except perhaps<br>possibly you) would declare =
such a language &quot;expressive&quot;.<br><br></div></div></div></div></bl=
ockquote><div>That&#39;s red herring. Keeping unspecified evaluation order =
does not forbid you specifying the order when needed, as I have said, just =
in a style that you don&#39;t want. This is quite opposite to &quot;all und=
efined&quot;, which actually gives you <i>no expressiveness</i>. Another ex=
ample is <a href=3D"http://wg21.cmeerw.net/cwg/issue1227">CWG1227</a>. The =
resolution is not good, but it is somewhat acceptable as the compromise bec=
ause we have no easy way to express ordered <span class=3D"msg">substitutio=
n </span>in such cases otherwise (without additional complicated modificati=
on to the language).<br><br>=C2=A0<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>On the =
contrary, specifying order of evaluation increases expressiveness because &=
quot;expressiveness&quot;<br>is the property of assigning meaning to writin=
g, and specifying order adds meaning in a context where<br>the order in whi=
ch things happen is manifestly important.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b0290aaa-9fcb-4394-9375-fc857f763071%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0290aaa-9fcb-4394-9375-fc857f763071=
%40isocpp.org</a>.<br />

------=_Part_1513_777941826.1457673660258--
------=_Part_1512_855388200.1457673660258--

.

------=_Part_1526_1347096880.1457674606525
Content-Type: multipart/alternative;
 boundary="----=_Part_1527_240381270.1457674606525"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=8812:20:43=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Mar 10, 2016 at 11:06 AM, Matthew Woehlke <mwoehlk...@gmail.com=
=20
> <javascript:>> wrote:
>
> In what manner is that ill-formed? Please cite the relevant standardese.
>
>
> 1.9 { Program execution }
> *If a side effect on a scalar object is unsequenced relative to either=20
> another side effect on the same scalar object or a value computation usin=
g=20
> the value of the same scalar object ... the behavior is undefined.*
>
> This statement contains multiple side effects (the ++category expressions=
)=20
> that are
> unsequenced with respect to each other.  That you are participating in=20
> this discussion
> and didn't realize this demonstrates my point; even experts, even people=
=20
> specifically
> involved in a discussion of order of evaluation, fail to see when code=20
> violates the rules.
>
> What's the correct response?  Well, I could laugh at you, call you=20
> incompetent, and
> declare that I would never hire a simpleton such as y
> ...

Your explanation is wrong. The side effect within a builtin *prefix *++ is=
=20
sequenced before the value computation of that expression after CWG637=20
<http://wg21.cmeerw.net/cwg/issue637> resolved. Value computation of result=
=20
different ++ expressions are chained by the overloaded << function calls,=
=20
thus they are sequenced indirectly by the rule of "sequenced before" rule=
=20
between function arguments and function body, and the transitive property=
=20
provided by the definition of "sequenced before" binary relationship. These=
=20
rules should also be in 1.9 IIRC.

I should apologize that I did not read your smelly code carefully. Your=20
explanation is right if it was postfix ++ or in C++98/03.

=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/2b03c87f-df18-4e15-8396-dd7ea0911c19%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8811=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:20:43=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>On Thu, Mar 10, 2016 at 11:06 AM, Matthew Woehlke <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"tYxhHxDtBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">mwoehlk...@gmail.com</a>&gt;</span> wrote:<blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">In what manner is that=
 ill-formed? Please cite the relevant standardese.</blockquote><div><br></d=
iv>1.9 { Program execution }<div><i>If a side effect on a scalar object is =
unsequenced relative to either another side effect on the same scalar objec=
t or a value computation using the value of the same scalar object ... the =
behavior is undefined.</i></div><div><i><br></i></div><div>This statement c=
ontains multiple side effects (the ++category expressions) that are<br>unse=
quenced with respect to each other.=C2=A0 That you are participating in thi=
s discussion<br>and didn&#39;t realize this demonstrates my point; even exp=
erts, even people specifically<br>involved in a discussion of order of eval=
uation, fail to see when code violates the rules.<br><br>What&#39;s the cor=
rect response?=C2=A0 Well, I could laugh at you, call you incompetent, and<=
br>declare that I would never hire a simpleton such as y</div></div></div><=
/div>...</blockquote><div>Your explanation is wrong. The side effect within=
 a builtin <i>prefix </i>++ is sequenced before the value computation of th=
at expression after <a href=3D"http://wg21.cmeerw.net/cwg/issue637">CWG637<=
/a> resolved. Value computation of result different ++ expressions are chai=
ned by the overloaded &lt;&lt; function calls, thus they are sequenced indi=
rectly by the rule of &quot;sequenced before&quot; rule between function ar=
guments and function body, and the transitive property provided by the defi=
nition of &quot;sequenced before&quot; binary relationship. These rules sho=
uld also be in 1.9 IIRC.<br><br>I should apologize that I did not read your=
 smelly code carefully. Your explanation is right if it was postfix ++ or i=
n C++98/03.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2b03c87f-df18-4e15-8396-dd7ea0911c19%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2b03c87f-df18-4e15-8396-dd7ea0911c19=
%40isocpp.org</a>.<br />

------=_Part_1527_240381270.1457674606525--
------=_Part_1526_1347096880.1457674606525--

.

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

I=E2=80=99ve been following this discussion for weeks now. So I just got cu=
rious
about Hyman's example and what my colleagues are going to think that the
result should be. So I prepared 4 questions and met 10 of them personally
and asked them the following. All 10 are senior software developers and C++
is main if not the only language in their projects.
Given this code:
std::cout << ++category << " Those that belong to the emperor\n"
          << ++category << " Embalmed ones\n"
          << ++category << " Those that, at a distance, resemble flies\n";
1- What do you think the result is/should be?
2- Is it possible that you wrote such a code in the past?
3- Can you for sure say that you won't write such a code in future or you
might write similar code and why?
4- If someone gives you this code to review, would you accept it or reject
it and why?

The results is:
1- 9/10 said it's 1-2-3 at the first glance and one said 0-1-2 but changed
it to 1-2-3 soon after.
2- 7/10 said they might have written such a code in the past and 3 said
they are sure they haven't because it's not their style.
3- 8/10 said they may write this kind of code in future depending on the
situation and 2 said they won't because it's not their style.
4- 8/10 said they will accept the code and 2 said they will reject it
because of the complexity and being suspicious.

My goal was to know the probability of such a code ending up in production
code in a small statistical sample and it's not representative of my
company by no means.
What's interesting is that none of them knew or mentioned that it is
undefined behavior.
Please note that I'm not an expert in surveys by no means. It was just a
personal experience which I thought might be interesting for you too.

On Fri, Mar 11, 2016 at 1:36 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:

>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 U=
TC+8=E4=B8=8A=E5=8D=8812:20:43=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On Thu, Mar 10, 2016 at 11:06 AM, Matthew Woehlke <mwoehlk...@gmail.com>
>> wrote:
>>
>> In what manner is that ill-formed? Please cite the relevant standardese.
>>
>>
>> 1.9 { Program execution }
>> *If a side effect on a scalar object is unsequenced relative to either
>> another side effect on the same scalar object or a value computation usi=
ng
>> the value of the same scalar object ... the behavior is undefined.*
>>
>> This statement contains multiple side effects (the ++category
>> expressions) that are
>> unsequenced with respect to each other.  That you are participating in
>> this discussion
>> and didn't realize this demonstrates my point; even experts, even people
>> specifically
>> involved in a discussion of order of evaluation, fail to see when code
>> violates the rules.
>>
>> What's the correct response?  Well, I could laugh at you, call you
>> incompetent, and
>> declare that I would never hire a simpleton such as y
>> ...
>
> Your explanation is wrong. The side effect within a builtin *prefix *++
> is sequenced before the value computation of that expression after CWG637
> <http://wg21.cmeerw.net/cwg/issue637> resolved. Value computation of
> result different ++ expressions are chained by the overloaded << function
> calls, thus they are sequenced indirectly by the rule of "sequenced befor=
e"
> rule between function arguments and function body, and the transitive
> property provided by the definition of "sequenced before" binary
> relationship. These rules should also be in 1.9 IIRC.
>
> I should apologize that I did not read your smelly code carefully. Your
> explanation is right if it was postfix ++ or in C++98/03.
>
>
>
> --
> You received this message because you are 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/2b03c87f-df1=
8-4e15-8396-dd7ea0911c19%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b03c87f-df=
18-4e15-8396-dd7ea0911c19%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/CALb3uoZ8z_8PgvHytafrOJ193r%2BmrT4wAbTeGa9TJtMgZ=
ZjvTA%40mail.gmail.com.

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

<div dir=3D"ltr"><font face=3D"Arial, Helvetica, sans-serif">I=E2=80=99ve b=
een following this discussion for weeks now. So I just got curious about=C2=
=A0Hyman&#39;s example and=C2=A0what my colleagues are going to think that =
the result should be. So I prepared 4 questions and met 10 of them personal=
ly and asked them the following. All 10 are senior software developers and =
C++ is main if not the only language in their projects.</font><div><font fa=
ce=3D"Arial, Helvetica, sans-serif">Given this code:</font></div><div><font=
 face=3D"monospace, monospace"><span style=3D"color:rgb(136,136,136);font-s=
ize:13px">std::cout &lt;&lt; ++category &lt;&lt; &quot; Those that belong t=
o the emperor\n&quot;=C2=A0</span><br style=3D"color:rgb(136,136,136);font-=
size:13px"><span style=3D"color:rgb(136,136,136);font-size:13px">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 &lt;&lt; ++category &lt;&lt; &quot; Embalmed ones\=
n&quot;=C2=A0</span><br style=3D"color:rgb(136,136,136);font-size:13px"><sp=
an style=3D"color:rgb(136,136,136);font-size:13px">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 &lt;&lt; ++category &lt;&lt; &quot; Those that, at a distance, r=
esemble flies\n&quot;;=C2=A0</span><br></font><div><span style=3D"font-fami=
ly:Arial,Helvetica,sans-serif;font-size:13px">1- What do you think the resu=
lt is/should be?</span></div><div><span style=3D"font-family:Arial,Helvetic=
a,sans-serif;font-size:13px">2- Is it possible that you wrote such a code i=
n the past?</span></div><div><span style=3D"font-family:Arial,Helvetica,san=
s-serif;font-size:13px">3- Can you for sure say that you won&#39;t write su=
ch a code in future or you might write similar code and why?</span></div><d=
iv><span style=3D"font-family:Arial,Helvetica,sans-serif;font-size:13px">4-=
 If someone gives you this code to review, would you accept it or reject it=
 and why?</span></div><div><span style=3D"font-family:Arial,Helvetica,sans-=
serif;font-size:13px"><br></span></div><div><font face=3D"Arial, Helvetica,=
 sans-serif">The results is:</font></div><div><font face=3D"Arial, Helvetic=
a, sans-serif">1- 9/10 said it&#39;s 1-2-3 at the first glance and one said=
 0-1-2 but changed it to 1-2-3 soon after.</font></div><div><font face=3D"A=
rial, Helvetica, sans-serif">2- 7/10 said they might have written such a co=
de in the past and 3 said they are sure they haven&#39;t because it&#39;s n=
ot their style.</font></div><div><font face=3D"Arial, Helvetica, sans-serif=
">3- 8/10 said they may write this kind of code in future depending on the =
situation and 2 said they won&#39;t because it&#39;s not their style.</font=
></div><div><font face=3D"Arial, Helvetica, sans-serif">4- 8/10 said they w=
ill accept the code and 2 said they will reject it because of the complexit=
y and being suspicious.</font></div><div><span style=3D"font-family:Arial,H=
elvetica,sans-serif;font-size:13px"><br></span></div><div><span style=3D"fo=
nt-family:Arial,Helvetica,sans-serif;font-size:13px">My goal was to know th=
e probability of such a code ending up in production code in a small=C2=A0<=
/span><font face=3D"Arial, Helvetica, sans-serif">statistical sample and it=
&#39;s not=C2=A0representative=C2=A0of my company by no means.</font></div>=
<div><span style=3D"font-family:Arial,Helvetica,sans-serif;font-size:13px">=
What&#39;s interesting is that none of them knew or mentioned that it is un=
defined behavior.</span></div><div><span style=3D"font-family:Arial,Helveti=
ca,sans-serif;font-size:13px">Please note that I&#39;m not an expert in sur=
veys by no means. It was just a personal experience which I thought might b=
e interesting for you too.</span></div></div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Fri, Mar 11, 2016 at 1:36 PM, FrankHB1=
989 <span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com" target=
=3D"_blank">frankhb1989@gmail.com</a>&gt;</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"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8811=
=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:20: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 dir=3D"ltr"><div><div>On Thu, Mar 10, 2016 at 11:06 AM, Matthew =
Woehlke <span dir=3D"ltr">&lt;<a rel=3D"nofollow">mwoehlk...@gmail.com</a>&=
gt;</span> wrote:<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">In what manner is that ill-formed? Please cite the relevant sta=
ndardese.</blockquote><div><br></div>1.9 { Program execution }<div><i>If a =
side effect on a scalar object is unsequenced relative to either another si=
de effect on the same scalar object or a value computation using the value =
of the same scalar object ... the behavior is undefined.</i></div><div><i><=
br></i></div><div>This statement contains multiple side effects (the ++cate=
gory expressions) that are<br>unsequenced with respect to each other.=C2=A0=
 That you are participating in this discussion<br>and didn&#39;t realize th=
is demonstrates my point; even experts, even people specifically<br>involve=
d in a discussion of order of evaluation, fail to see when code violates th=
e rules.<br><br>What&#39;s the correct response?=C2=A0 Well, I could laugh =
at you, call you incompetent, and<br>declare that I would never hire a simp=
leton such as y</div></div></div></div>...</blockquote><div>Your explanatio=
n is wrong. The side effect within a builtin <i>prefix </i>++ is sequenced =
before the value computation of that expression after <a href=3D"http://wg2=
1.cmeerw.net/cwg/issue637" target=3D"_blank">CWG637</a> resolved. Value com=
putation of result different ++ expressions are chained by the overloaded &=
lt;&lt; function calls, thus they are sequenced indirectly by the rule of &=
quot;sequenced before&quot; rule between function arguments and function bo=
dy, and the transitive property provided by the definition of &quot;sequenc=
ed before&quot; binary relationship. These rules should also be in 1.9 IIRC=
..<br><br>I should apologize that I did not read your smelly code carefully.=
 Your explanation is right if it was postfix ++ or in C++98/03.<br><br>=C2=
=A0<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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/2b03c87f-df18-4e15-8396-dd7ea0911c19%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2b03c87f-df18-=
4e15-8396-dd7ea0911c19%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALb3uoZ8z_8PgvHytafrOJ193r%2BmrT4wAb=
TeGa9TJtMgZZjvTA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALb3uoZ8z_8Pgv=
HytafrOJ193r%2BmrT4wAbTeGa9TJtMgZZjvTA%40mail.gmail.com</a>.<br />

--001a11444b90cc0200052dc24f3e--

.

On 2016-03-11 04:11, Reza Jahanbakhshi wrote:
> I=E2=80=99ve been following this discussion for weeks now. So I just got =
curious
> about Hyman's example and what my colleagues are going to think that the
> result should be. So I prepared 4 questions and met 10 of them personally
> and asked them the following. All 10 are senior software developers and C=
++
> is main if not the only language in their projects.
> Given this code:
> std::cout << ++category << " Those that belong to the emperor\n"
>           << ++category << " Embalmed ones\n"
>           << ++category << " Those that, at a distance, resemble flies\n"=
;
> 1- What do you think the result is/should be?
> 2- Is it possible that you wrote such a code in the past?
> 3- Can you for sure say that you won't write such a code in future or you
> might write similar code and why?
> 4- If someone gives you this code to review, would you accept it or rejec=
t
> it and why?
>=20
> The results is:
> 1- 9/10 said it's 1-2-3 at the first glance and one said 0-1-2 but change=
d
> it to 1-2-3 soon after.

GCC disagrees. At least with a simplified version:

  cout << ++i << ++i << ++i;

....the result is 333. Moreover, the compiled pseudocode is roughly:

  i +=3D 3;
  operator<<(cout, i);
  operator<<(cout, i);
  operator<<(cout, i);

--=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/nbukp4%2457u%241%40ger.gmane.org.

.

On 11 March 2016 at 16:29, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2016-03-11 04:11, Reza Jahanbakhshi wrote:
>> The results is:
>> 1- 9/10 said it's 1-2-3 at the first glance and one said 0-1-2 but changed
>> it to 1-2-3 soon after.
> GCC disagrees. At least with a simplified version:

That's not the point. The point is that no user, expert or non-expert,
can give the right answer.
Mostly because there is no right answer. That makes it freakishly
difficult to reason
about any code that has multiple subexpressions in an expression,
which is exactly why
expression evaluation order is proposed to be specified.

--
You received this message because you are 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/CAFk2RUbY3nMEZAXDuLb49e_12XygxKMfAmbphTY_o%2BBuhLZ_JQ%40mail.gmail.com.

.

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

On Fri, Mar 11, 2016 at 9:29 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2016-03-11 04:11, Reza Jahanbakhshi wrote:
> > The results is:
> > 1- 9/10 said it's 1-2-3 at the first glance and one said 0-1-2 but
> changed
> > it to 1-2-3 soon after.
>
> GCC disagrees. At least with a simplified version:
>
>   cout << ++i << ++i << ++i;
>
> ...the result is 333. Moreover, the compiled pseudocode is roughly:
>
>   i += 3;
>   operator<<(cout, i);
>   operator<<(cout, i);
>   operator<<(cout, i);
>

Does it matter? Its UB anyway -- the compiler can do whatever it wants. I
think someone pointed this out elsethread.

--
You received this message because you are 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/CALEPxftBak_Dr54u80NeGCbs6Kp_qiEg_ZCN1bX4nrULvmSpTw%40mail.gmail.com.

--001a113f1e420cb2f0052dc707ee
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, Mar 11, 2016 at 9:29 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016-03-11 =
04:11, Reza Jahanbakhshi wrote:<br>&gt; The results is:<br>
&gt; 1- 9/10 said it&#39;s 1-2-3 at the first glance and one said 0-1-2 but=
 changed<br>
&gt; it to 1-2-3 soon after.<br>
<br>
GCC disagrees. At least with a simplified version:<br>
<br>
=C2=A0 cout &lt;&lt; ++i &lt;&lt; ++i &lt;&lt; ++i;<br>
<br>
....the result is 333. Moreover, the compiled pseudocode is roughly:<br>
<br>
=C2=A0 i +=3D 3;<br>
=C2=A0 operator&lt;&lt;(cout, i);<br>
=C2=A0 operator&lt;&lt;(cout, i);<br>
=C2=A0 operator&lt;&lt;(cout, i);<br></blockquote><div><br></div><div>Does =
it matter? Its UB anyway -- the compiler can do whatever it wants. I think =
someone pointed this out elsethread.=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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxftBak_Dr54u80NeGCbs6Kp_qiEg_ZCN=
1bX4nrULvmSpTw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxftBak_Dr54u=
80NeGCbs6Kp_qiEg_ZCN1bX4nrULvmSpTw%40mail.gmail.com</a>.<br />

--001a113f1e420cb2f0052dc707ee--

.

On 2016-03-11 09:43, Ville Voutilainen wrote:
> On 11 March 2016 at 16:29, Matthew Woehlke wrote:
>> On 2016-03-11 04:11, Reza Jahanbakhshi wrote:
>>> The results is:
>>> 1- 9/10 said it's 1-2-3 at the first glance and one said 0-1-2 but changed
>>> it to 1-2-3 soon after.
>> GCC disagrees. At least with a simplified version:
>
> That's not the point. The point is that no user, expert or non-expert,
> can give the right answer.

Ack... that's what I *meant* :-), modulo poor phrasing.

(Oh, and... FWIW, clang AFAICT gives the "expected" 123...)

> Mostly because there is no right answer.

Right. Both the GCC and clang behaviors are permissible results. I
didn't mean to imply that one was "right" or "wrong"; rather, that the
result that the poll respondents gave is a) not the *only* permissible
result, and b) at least one compiler *does* give a different (also
permissible) 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/nbumrd%247du%241%40ger.gmane.org.

.

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

On Fri, Mar 11, 2016 at 12:36 AM, FrankHB1989 <frankhb1989@gmail.com> wrote=
:

> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 U=
TC+8=E4=B8=8A=E5=8D=8812:20:43=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> 1.9 { Program execution }
>> *If a side effect on a scalar object is unsequenced relative to either
>> another side effect on the same scalar object or a value computation usi=
ng
>> the value of the same scalar object ... the behavior is undefined.*
>>
>> This statement contains multiple side effects (the ++category
>> expressions) that are
>> unsequenced with respect to each other.
>> ...
>
> Your explanation is wrong. The side effect within a builtin *prefix *++
> is sequenced before the value computation of that expression after CWG637
> <http://wg21.cmeerw.net/cwg/issue637> resolved. Value computation of
> result different ++ expressions are chained by the overloaded << function
> calls, thus they are sequenced indirectly by the rule of "sequenced befor=
e"
> rule between function arguments and function body, and the transitive
> property provided by the definition of "sequenced before" binary
> relationship. These rules should also be in 1.9 IIRC.
>
> I should apologize that I did not read your smelly code carefully. Your
> explanation is right if it was postfix ++ or in C++98/03.
>

I doubt that my explanation is wrong; I have a copy of a C++17 working
draft (N4527) and I see nothing there that supports your theory.  A
simplified version of my code is s.f(++i).f(++i).  If you believe that this
is not undefined behavior, please quote the relevant portions of the
standard that require the two appearances of ++i to be sequenced with
respect to each other. (If you cannot, as I believe you will discover, this
will be yet more evidence of experts not understanding order of evaluation.=
)

On a related note, your continuing characterization of such code as "bad"
and "smelly" carries no weight with me.  The reason why such code is
problematic is that the language definition is wrong.  If the language were
correct, this code would be fine, its purpose readily apparent and its
functioning understood.  Attacking the code instead of the language is an
excuse to maintain a flawed status quo and an attempt to sway people away
from fixing it.

--=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/CAHSYqdayy_0yQ7U0E7vpGymvagsPUF7%2Br4zv5U0LW7Xjt=
kB3gA%40mail.gmail.com.

--001a1143f1546fc1a8052dc7e458
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, Mar 11, 2016 at 12:36 AM, FrankHB1989 <span dir=3D"ltr">&lt;<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:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=
=A8 2016=E5=B9=B43=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=
=B8=8A=E5=8D=8812:20:43=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"><div><=
div>1.9 { Program execution }<div><i>If a side effect on a scalar object is=
 unsequenced relative to either another side effect on the same scalar obje=
ct or a value computation using the value of the same scalar object ... the=
 behavior is undefined.</i></div><div><i><br></i></div><div>This statement =
contains multiple side effects (the ++category expressions) that are<br>uns=
equenced with respect to each other.</div></div></div></div></span>...</blo=
ckquote><div>Your explanation is wrong. The side effect within a builtin <i=
>prefix </i>++ is sequenced before the value computation of that expression=
 after <a href=3D"http://wg21.cmeerw.net/cwg/issue637" target=3D"_blank">CW=
G637</a> resolved. Value computation of result different ++ expressions are=
 chained by the overloaded &lt;&lt; function calls, thus they are sequenced=
 indirectly by the rule of &quot;sequenced before&quot; rule between functi=
on arguments and function body, and the transitive property provided by the=
 definition of &quot;sequenced before&quot; binary relationship. These rule=
s should also be in 1.9 IIRC.<br><br>I should apologize that I did not read=
 your smelly code carefully. Your explanation is right if it was postfix ++=
 or in C++98/03.</div></div></blockquote><div><br>I doubt that my explanati=
on is wrong; I have a copy of a C++17 working draft (N4527) and I see nothi=
ng there that supports your theory.=C2=A0 A simplified version of my code i=
s <font face=3D"monospace, monospace">s.f(++i).f(++i)</font>.=C2=A0 If you =
believe that this is not undefined behavior, please quote the relevant port=
ions of the standard that require the two appearances of <font face=3D"mono=
space, monospace">++i</font><font face=3D"arial, helvetica, sans-serif"> </=
font>to be sequenced with respect to each other. (If you cannot, as I belie=
ve you will discover, this will be yet more evidence of experts not underst=
anding order of evaluation.)<br><br>On a related note, your continuing char=
acterization of such code as &quot;bad&quot; and &quot;smelly&quot; carries=
 no weight with me.=C2=A0 The reason why such code is problematic is that t=
he language definition is wrong.=C2=A0 If the language were correct, this c=
ode would be fine, its purpose readily apparent and its functioning underst=
ood.=C2=A0 Attacking the code instead of the language is an excuse to maint=
ain a flawed status quo and an attempt to sway people away from fixing it.<=
/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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdayy_0yQ7U0E7vpGymvagsPUF7%2Br4=
zv5U0LW7XjtkB3gA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdayy_0yQ7=
U0E7vpGymvagsPUF7%2Br4zv5U0LW7XjtkB3gA%40mail.gmail.com</a>.<br />

--001a1143f1546fc1a8052dc7e458--

.

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

On a side note, because I didn't give the correct answer right after to
some of them, they came after me later on and told me that they made a
mistake and after a little investigation they came to conclusion that,
according to this standard excerpt and etc, this is UB. Maybe they felt bad
because after so many years of experience they made such a mistake. But I
told them that the point of these questions wasn't to measure you
competence. I just wanted to know that what do you think this code will or
should output. And also to measure the probability of this kind of code
ending up in production environment in a small statistical group. Please
note that I'm not implying that this result applies everywhere or even to
my other colleagues. I'm just sharing my small experiment here.
Anyway, I hope that I've done a good deed today, advancing the C++
knowledge of a few people :)

On Fri, Mar 11, 2016 at 11:05 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2016-03-11 09:43, Ville Voutilainen wrote:
> > On 11 March 2016 at 16:29, Matthew Woehlke wrote:
> >> On 2016-03-11 04:11, Reza Jahanbakhshi wrote:
> >>> The results is:
> >>> 1- 9/10 said it's 1-2-3 at the first glance and one said 0-1-2 but
> changed
> >>> it to 1-2-3 soon after.
> >> GCC disagrees. At least with a simplified version:
> >
> > That's not the point. The point is that no user, expert or non-expert,
> > can give the right answer.
>
> Ack... that's what I *meant* :-), modulo poor phrasing.
>
> (Oh, and... FWIW, clang AFAICT gives the "expected" 123...)
>
> > Mostly because there is no right answer.
>
> Right. Both the GCC and clang behaviors are permissible results. I
> didn't mean to imply that one was "right" or "wrong"; rather, that the
> result that the poll respondents gave is a) not the *only* permissible
> result, and b) at least one compiler *does* give a different (also
> permissible) 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/nbumrd%247du%241%40ger.gmane.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/CALb3uoZ_54X8kHPEi77s80%3DhzLWroAJZN2bv-LXKQ03%2BGb-_oA%40mail.gmail.com.

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

<div dir=3D"ltr">On a side note, because I didn&#39;t give the correct answ=
er=C2=A0right after=C2=A0to some of them,=C2=A0they came after me later on =
and told me that they made a mistake and after a little investigation they =
came to conclusion that, according to this standard excerpt and etc,=C2=A0t=
his is UB. Maybe they felt bad because after so many years of experience th=
ey made such a mistake. But I told them that the point of these questions w=
asn&#39;t to measure you competence. I just wanted to know that what do you=
 think this code will or should output. And also to measure the probability=
 of this kind of code ending up in production environment in a small statis=
tical group. Please note that I&#39;m not implying that this result applies=
 everywhere or even to my other colleagues. I&#39;m just sharing my small e=
xperiment here.<div>Anyway, I hope that I&#39;ve done a good deed today, ad=
vancing the C++ knowledge of a few people :)=C2=A0</div></div><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Mar 11, 2016 at 11:05 =
PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@=
gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">On 2016-03-11 09:43, Ville Voutilainen w=
rote:<br>
<span class=3D"">&gt; On 11 March 2016 at 16:29, Matthew Woehlke wrote:<br>
&gt;&gt; On 2016-03-11 04:11, Reza Jahanbakhshi wrote:<br>
&gt;&gt;&gt; The results is:<br>
&gt;&gt;&gt; 1- 9/10 said it&#39;s 1-2-3 at the first glance and one said 0=
-1-2 but changed<br>
&gt;&gt;&gt; it to 1-2-3 soon after.<br>
&gt;&gt; GCC disagrees. At least with a simplified version:<br>
&gt;<br>
&gt; That&#39;s not the point. The point is that no user, expert or non-exp=
ert,<br>
&gt; can give the right answer.<br>
<br>
</span>Ack... that&#39;s what I *meant* :-), modulo poor phrasing.<br>
<br>
(Oh, and... FWIW, clang AFAICT gives the &quot;expected&quot; 123...)<br>
<span class=3D""><br>
&gt; Mostly because there is no right answer.<br>
<br>
</span>Right. Both the GCC and clang behaviors are permissible results. I<b=
r>
didn&#39;t mean to imply that one was &quot;right&quot; or &quot;wrong&quot=
;; rather, that the<br>
result that the poll respondents gave is a) not the *only* permissible<br>
result, and b) at least one compiler *does* give a different (also<br>
permissible) result.<br>
<br>
--<br>
Matthew<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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/nbumrd%247du%241%40ger.gmane.o=
rg" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/nbumrd%247du%241%40ger.gmane.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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALb3uoZ_54X8kHPEi77s80%3DhzLWroAJZN2=
bv-LXKQ03%2BGb-_oA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALb3uoZ_54X8=
kHPEi77s80%3DhzLWroAJZN2bv-LXKQ03%2BGb-_oA%40mail.gmail.com</a>.<br />

--001a11444b90a58614052dc8061b--

.

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

On Fri, Mar 11, 2016 at 11:00 AM, Reza Jahanbakhshi <
reza.jahanbakhshi@gmail.com> wrote:

> But I told them that the point of these questions wasn't to measure you
> competence.
>

Right.

Even very experienced C++ programmers do not notice problems with undefined
behavior due to order of evaluation, for two reasons.  First, they do not
remember that order of evaluation is an issue, since most of the time it is
not, and they do not know or remember the rules governing it.  Second, the
code communicates its intent so strongly that it is psychologically
difficult to accept that it does not do exactly what it appears to.  Recall
how novel it was to accept that f(new T, new T) could leak memory even when
the parameters were smart pointers.  (Another nail in the coffin for
unspecified order, papered over with more accusations of bad code - "don't
use new directly".)

This means that the notion that such code will be weeded out by review is
fatally flawed; neither the authors nor the reviewers will see the
problem.  At best, with multiple increments, reviewers may feel some
suspicion because they may recall some folklore that such code is bad.
When the code involves multiple function calls and unspecified rather than
undefined behavior, I doubt that many reviewers will ever notice.

--
You received this message because you are 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/CAHSYqdZT2Ur7ah1gswgfK0M%2BCv5vb6erbtjUGEnAOTMsW0C_%2Bg%40mail.gmail.com.

--001a114783cc781ec9052dc85735
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, Mar 11, 2016 at 11:00 AM, Reza Jahanbakhshi <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:reza.jahanbakhshi@gmail.com" target=3D"_blank">reza.jahanbakhs=
hi@gmail.com</a>&gt;</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">But I told them that the point of these questions wasn&#39;t to =
measure you competence.</div></blockquote><div><br>Right.<br><br>Even very =
experienced C++ programmers do not notice problems with undefined behavior =
due to order of evaluation, for two reasons.=C2=A0 First, they do not remem=
ber that order of evaluation is an issue, since most of the time it is not,=
 and they do not know or remember the rules governing it.=C2=A0 Second, the=
 code communicates its intent so strongly that it is psychologically diffic=
ult to accept that it does not do exactly what it appears to.=C2=A0 Recall =
how novel it was to accept that <font face=3D"monospace, monospace">f(new T=
, new T)</font> could leak memory even when the parameters were smart point=
ers. =C2=A0(Another nail in the coffin for unspecified order, papered over =
with more accusations of bad code - &quot;don&#39;t use <font face=3D"monos=
pace, monospace">new</font> directly&quot;.)<br><br>This means that the not=
ion that such code will be weeded out by review is fatally flawed; neither =
the authors nor the reviewers will see the problem.=C2=A0 At best, with mul=
tiple increments, reviewers may feel some suspicion because they may recall=
 some folklore that such code is bad.=C2=A0 When the code involves multiple=
 function calls and unspecified rather than undefined behavior, I doubt tha=
t many reviewers will ever notice.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZT2Ur7ah1gswgfK0M%2BCv5vb6erbt=
jUGEnAOTMsW0C_%2Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZT2Ur7=
ah1gswgfK0M%2BCv5vb6erbtjUGEnAOTMsW0C_%2Bg%40mail.gmail.com</a>.<br />

--001a114783cc781ec9052dc85735--

.

--047d7b2e47c8ffd087052dc8a416
Content-Type: text/plain; charset=UTF-8

On 10 Mar 2016 15:51, "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
>
> On Thu, Mar 10, 2016 at 1:04 AM, FrankHB1989 <frankhb1989@gmail.com>
wrote:
>>
>> Can you illustrate some ways to guarantee the implementations only using
as-if rules behave as efficient as any possible implementations with aid of
unsequenced evaluation rules?
>
>
> No.  I'm sure there are programs which will become slower.  I don't
care.

Some will.

> Statements
> are sequenced, and we rely on compilers to optimize when they can, and we
live quite
> comfortably with that.

There's nothing wrong with sequencing; to express a program being able to
employ sequencing is great. But we need to be able to express its absence
as well.

>  I just don't find the "but optimization!" arguments compelling.
> Better language design is better even if it has costs.  That's why we
don't program in
> assembler.

I really don't follow. Assembler is far less amenable to optimization than
high level languages.

> The freedom of compilers is unimportant.  Compilers must already follow
thousands of nitpicky
> rules which constrain what they do.

That makes their remaining freedom more important, not less.

> Your argument about decreasing expressiveness of the
> language is wrong; were you correct, a language standard that said that
all programs have
> undefined behavior and the standard imposes no requirements on them would
have the maximum
> possible expressiveness.  But such a language would be useless, and no
one (except perhaps
> possibly you) would declare such a language "expressive".

That's not what we mean by expressiveness.

> On the contrary, specifying order of evaluation increases expressiveness
because "expressiveness"
> is the property of assigning meaning to writing, and specifying order
adds meaning in a context where
> the order in which things happen is manifestly important.

That's also not what we mean by expressiveness. Expressive power is a
measure of the breadth of ideas that can be represented and communicated in
a language. C++ with a defined order of evaluation cannot express the idea
of indeterminate sequencing of evaluation of operands, so is less
expressive.

--
You received this message because you are 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/CAJnLdOa8KQx%2BT-fwDVqJNZENh%2Bysu%3D8pHa_PKMBZ-qtc1nxdgQ%40mail.gmail.com.

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

<div dir=3D"ltr"><p dir=3D"ltr"><br>
On 10 Mar 2016 15:51, &quot;Hyman Rosen&quot; &lt;<a href=3D"mailto:hyman.r=
osen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Thu, Mar 10, 2016 at 1:04 AM, FrankHB1989 &lt;<a href=3D"mailto:fra=
nkhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&gt; wrote:<=
br>
&gt;&gt;<br>
&gt;&gt; Can you illustrate some ways to guarantee the implementations only=
 using as-if rules behave as efficient as any possible implementations with=
 aid of unsequenced evaluation rules?<br>
&gt;<br>
&gt;<br>
&gt; No.=C2=A0 I&#39;m sure there are programs which will become slower.=C2=
=A0 I don&#39;t care.=C2=A0 </p>
<p dir=3D"ltr">Some will. </p>
<p dir=3D"ltr">&gt; Statements<br>
&gt; are sequenced, and we rely on compilers to optimize when they=C2=A0can=
, and we live quite<br>
&gt; comfortably with that.</p>
<p dir=3D"ltr">There&#39;s nothing wrong with sequencing; to express a prog=
ram being able to employ sequencing is great. But we need to be able to exp=
ress its absence as well. </p>
<p dir=3D"ltr">&gt;=C2=A0 I just don&#39;t find the &quot;but optimization!=
&quot; arguments compelling.<br>
&gt; Better language=C2=A0design is better even if it has costs.=C2=A0 That=
&#39;s why we don&#39;t program in<br>
&gt; assembler.</p>
<p dir=3D"ltr">I really don&#39;t follow. Assembler is far less amenable to=
 optimization than high level languages. </p>
<p dir=3D"ltr">&gt; The freedom of compilers is unimportant.=C2=A0 Compiler=
s must already follow thousands of nitpicky<br>
&gt; rules which constrain what they do.=C2=A0</p>
<p dir=3D"ltr">That makes their remaining freedom more important, not less.=
 </p>
<p dir=3D"ltr">&gt; Your argument about decreasing expressiveness of=C2=A0t=
he<br>
&gt; language is wrong; were you correct, a language standard that said tha=
t all programs have<br>
&gt; undefined behavior and the standard imposes no requirements on them wo=
uld have the maximum<br>
&gt; possible expressiveness.=C2=A0 But such a language would be useless, a=
nd no one (except perhaps<br>
&gt; possibly you) would declare such a language &quot;expressive&quot;.</p=
>
<p dir=3D"ltr">That&#39;s not what we mean by expressiveness. </p>
<p dir=3D"ltr">&gt; On the contrary, specifying order of evaluation increas=
es expressiveness because &quot;expressiveness&quot;<br>
&gt; is the property of assigning meaning to writing, and specifying order =
adds meaning in a context where<br>
&gt; the order in which things happen is manifestly important.</p>
<p dir=3D"ltr">That&#39;s also not what we mean by expressiveness. Expressi=
ve power is a measure of the breadth of ideas that can be represented and c=
ommunicated in a language. C++ with a defined order of evaluation cannot ex=
press the idea of indeterminate sequencing of evaluation of operands, so is=
 less expressive.</p>
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOa8KQx%2BT-fwDVqJNZENh%2Bysu%3D=
8pHa_PKMBZ-qtc1nxdgQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOa8KQ=
x%2BT-fwDVqJNZENh%2Bysu%3D8pHa_PKMBZ-qtc1nxdgQ%40mail.gmail.com</a>.<br />

--047d7b2e47c8ffd087052dc8a416--

.

--047d7b3a9b3a9aa6c4052dc8e25e
Content-Type: text/plain; charset=UTF-8

On Thu, Mar 10, 2016 at 5:22 PM, Brent Friedman <fourthgeek@gmail.com>
wrote:

>
> > If the compiler can't optimize effectively because the side-effects of
>> the subexpressions are unknown, then it seems unlikely that significant
>> optimization was going to happen anyways.
>> What is the justification for this assertion? CSE, for example, can be
>> applied even when its result is passed to an opaque function.
>
>
> My assertion is a matter of personal expectations. If I am calling
> functions whose definitions are not visible I do not expect the compiler to
> do a good job of optimizing my code. I'm not saying that all optimizations
> are off the table, but that the optimizer is significantly hampered and
> expectations should be set accordingly.
>

Sure; that doesn't mean we should give up. Often an opaque function call is
a virtual member function, which branch will typically be predicted
correctly, so the overhead of the containing expression remains significant.


> Given the extent of these discussions, it seems likely that if we do
> specify evaluation order, compilers will provide an option / migration path
> for users relying on old behavior. If there is real value to be had there
> then I would expect compiler vendors to provide a variety of nonstandard
> options for the discerning customer. The fact that this might happen
> wouldn't be evidence that we made a bad decision. Vendors provide all sorts
> of nonstandard extensions to fulfill obscure scenarios or platform-specific
> optimizations. It would be nice to have a trustworthy common baseline that
> can be relied on.
>

Vendors prefer to provide conforming extensions over providing
nonconforming extensions. An extension providing a fixed order of
evaluation would be conforming today, whatever that order was; tomorrow if
it specified a different order of evaluation from the standardized order it
would be noncompliant. Today it could be enabled at liberty wherever
required, since conformant library and third-party code does not depend on
order of evaluation; tomorrow, with library and third-party code depending
on a "standard" order of evaluation, it might well be unusable or would
have to be implemented as a pragma, on a per-line basis, significantly
complicating implementation and usage.


> Besides, the issue is not whether the behavior is unspecified, it is
>> whether it cannot be proven not to be unspecified. We have already covered
>> opaque functions that the type system does not allow us to assert do not
>> modify memory accessed elsewhere in the expression; similarly, one can have
>> pointers that cannot be proved not to alias:
>> int g(int* p) { return *p = 0; }
>> int h(int* q) { return *q; }
>> int f(int* p, int* q) { return g(p) + h(q); }
>> With free ordering the write to *p and read from *q can execute in
>> parallel; under strict ordering the compiler must order the read after the
>> write, or must test p against q.
>
>
> Right, this is why I think we should refocus our discussion on semantics.
> What do we *want *this code to mean? Should it mean "read the manual for
> each compiler you are currently using" or should it have a well-defined
> meaning?
>

 Why would you care about the meaning if p and q alias, if the program
semantics ensure they never alias?


> > Though the syntax is handy, you can imagine that expressions like this
>> are really dangerous for any side-effects they might have. Code like this
>> definitely wants an evaluation order.
>> I don't see anything there that would care what order the subexpressions
>> are evaluated in. Am I missing something?
>> > There's a fair argument that this code shouldn't be written like this
>> in C++ today, but there's also a fair argument that this is a useful way of
>> writing some things and maybe we should think about making code like this
>> less dangerous. At least in our case, this is also code where performance
>> is of effectively 0 concern since it is dead cold.
>> That looks to me like an initialization, so it should be possible to
>> write using list-initialization syntax. It might be too late for that
>> particular API, but a wrapper API or next version should be able to manage
>> it.
>
>
> I was attempting to provide a simplified version but I think I did a
> disservice in the process. The actual system is quite a bit more
> complicated.
>
> Here's some documentation on that UI framework, the bottom of the page
> starts giving you some idea of how it is designed to build large UI
> hierarchies as one big expression. It's very easy to have an order of
> evaluation issue, as you are no longer thinking in terms of expressions,
> but in terms of simply declaring nested objects. This is really an  EDSL.
> In short, this framework builds up an entire UI hierarchy typically as a
> single expression. The examples listed here are relatively simple, but when
> two widgets is a 30 line expression, an actually useful UI may be a
> several-hundred-line expression. There's no way someone can evaluate each
> subexpression for conflicting side-effects.
>
>
> https://docs.unrealengine.com/latest/INT/Programming/Slate/Widgets/index.html
>
> And again it's easy to argue that maybe code like this shouldn't be
> written, but clearly it is very useful. We're hampering the expressivity of
> EDSLs if we say that writing code like this will forever be bad style
> because we refuse to guarantee an evaluation order. List initialization
> can't be used because this framework relies on shared_from_this which
> cannot be used in a constructor. To support that it relies on two-phase
> initialization, which is hidden by the tricks of the EDSL.
>

That's impressive! But I don't see why using that framework that can't
coexist with free order of evaluation; there would only be a problem if you
start using and modifying the values of variables as widget construction
parameters. Would you want to do this? - I don't have any experience with
how game UIs are designed.

--
You received this message because you are 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/CAJnLdOZmYHpULbuN4ovLr-1GGa8a6Z-W85Nkk%3DmUMrf0vZs4bw%40mail.gmail.com.

--047d7b3a9b3a9aa6c4052dc8e25e
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, Mar 10, 2016 at 5:22 PM, Brent Friedman <span dir=3D"ltr">&lt;<a href=
=3D"mailto:fourthgeek@gmail.com" target=3D"_blank">fourthgeek@gmail.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"><div>=
<br></div><div><blockquote class=3D"gmail_quote" style=3D"color:rgb(80,0,80=
);font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">&gt; If=
 the compiler can&#39;t optimize effectively because the side-effects of th=
e subexpressions are unknown, then it seems unlikely that significant optim=
ization was going to happen anyways.<br>What is the justification for this =
assertion? CSE, for example, can be applied even when its result is passed =
to an opaque function.</blockquote><div style=3D"color:rgb(80,0,80);font-si=
ze:12.8px"><br></div><div style=3D"color:rgb(80,0,80);font-size:12.8px">My =
assertion is a matter of personal expectations. If I am calling functions w=
hose definitions are not visible I do not expect the compiler to do a good =
job of optimizing my code. I&#39;m not saying that all optimizations are of=
f the table, but that the optimizer is significantly hampered and expectati=
ons should be set accordingly.</div></div></div></blockquote><div><br></div=
><div>Sure; that doesn&#39;t mean we should give up. Often an opaque functi=
on call is a virtual member function, which branch will typically be predic=
ted correctly, so the overhead of the containing expression remains signifi=
cant.</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"><div dir=3D"ltr"=
><div><div style=3D"color:rgb(80,0,80);font-size:12.8px">Given the extent o=
f these discussions, it seems likely that if we do specify evaluation order=
, compilers will provide an option / migration path for users relying on ol=
d behavior. If there is real value to be had there then I would expect comp=
iler vendors to provide a variety of nonstandard options for the discerning=
 customer. The fact that this might happen wouldn&#39;t be evidence that we=
 made a bad decision. Vendors provide all sorts of nonstandard extensions t=
o fulfill obscure scenarios or platform-specific optimizations. It would be=
 nice to have a trustworthy common baseline that can be relied on.</div></d=
iv></div></blockquote><div><br></div><div>Vendors prefer to provide conform=
ing extensions over providing nonconforming extensions. An extension provid=
ing a fixed order of evaluation would be conforming today, whatever that or=
der was; tomorrow if it specified a different order of evaluation from the =
standardized order it would be noncompliant. Today it could be enabled at l=
iberty wherever required, since conformant library and third-party code doe=
s not depend on order of evaluation; tomorrow, with library and third-party=
 code depending on a &quot;standard&quot; order of evaluation, it might wel=
l be unusable or would have to be implemented as a pragma, on a per-line ba=
sis, significantly complicating implementation and usage.</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 dir=3D"ltr"><blockquote 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" class=3D"gmail_quote">Besid=
es, the issue is not whether the behavior is unspecified, it is whether it =
cannot be proven not to be unspecified. We have already covered opaque func=
tions that the type system does not allow us to assert do not modify memory=
 accessed elsewhere in the expression; similarly, one can have pointers tha=
t cannot be proved not to alias:<br>int g(int* p) { return *p =3D 0; }<br>i=
nt h(int* q) { return *q; }<br>int f(int* p, int* q) { return g(p) + h(q); =
}<br><span style=3D"font-size:12.8px">With free ordering the write to *p an=
d read from *q can execute in parallel; under strict ordering the compiler =
must order the read after the write, or must test p against q.</span></bloc=
kquote><div><br></div><div>Right, this is why I think we should refocus our=
 discussion on semantics. What do we <i>want </i>this code to mean? Should =
it mean &quot;read the manual for each compiler you are currently using&quo=
t; or should it have a well-defined meaning?</div></div></blockquote><div><=
br></div><div>=C2=A0Why would you care about the meaning if p and q alias, =
if the program semantics ensure they never alias?</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:=
12.8px"><blockquote 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:1e=
x" class=3D"gmail_quote">&gt; Though the syntax is handy, you can imagine t=
hat expressions like this are really dangerous for any side-effects they mi=
ght have. Code like this definitely wants an evaluation order.<br>I don&#39=
;t see anything there that would care what order the subexpressions are eva=
luated in. Am I missing something?<br>&gt; There&#39;s a fair argument that=
 this code shouldn&#39;t be written like this in C++ today, but there&#39;s=
 also a fair argument that this is a useful way of writing some things and =
maybe we should think about making code like this less dangerous. At least =
in our case, this is also code where performance is of effectively 0 concer=
n since it is dead cold.<br>That looks to me like an initialization, so it =
should be possible to write using list-initialization syntax. It might be t=
oo late for that particular API, but a wrapper API or next version should b=
e able to manage it.</blockquote><div>=C2=A0</div></span></div><div>I was a=
ttempting to provide a simplified version but I think I did a disservice in=
 the process. The actual system is quite a bit more complicated.</div><div>=
<br></div><div>Here&#39;s some documentation on that UI framework, the bott=
om of the page starts giving you some idea of how it is designed to build l=
arge UI hierarchies as one big expression. It&#39;s very easy to have an or=
der of evaluation issue, as you are no longer thinking in terms of expressi=
ons, but in terms of simply declaring nested objects. This is really an =C2=
=A0EDSL. In short, this framework builds up an entire UI hierarchy typicall=
y as a single expression. The examples listed here are relatively simple, b=
ut when two widgets is a 30 line expression, an actually useful UI may be a=
 several-hundred-line expression. There&#39;s no way someone can evaluate e=
ach subexpression for conflicting side-effects.</div><div><br></div><div><a=
 href=3D"https://docs.unrealengine.com/latest/INT/Programming/Slate/Widgets=
/index.html" target=3D"_blank">https://docs.unrealengine.com/latest/INT/Pro=
gramming/Slate/Widgets/index.html</a></div><div><br></div><div>And again it=
&#39;s easy to argue that maybe code like this shouldn&#39;t be written, bu=
t clearly it is very useful. We&#39;re hampering the expressivity of EDSLs =
if we say that writing code like this will forever be bad style because we =
refuse to guarantee an evaluation order. List initialization can&#39;t be u=
sed because this framework relies on shared_from_this which cannot be used =
in a constructor. To support that it relies on two-phase initialization, wh=
ich is hidden by the tricks of the EDSL.</div></div></blockquote><div><br><=
/div><div>That&#39;s impressive! But I don&#39;t see why using that framewo=
rk that can&#39;t coexist with free order of evaluation; there would only b=
e a problem if you start using and modifying the values of variables as wid=
get construction parameters. Would you want to do this? - I don&#39;t have =
any experience with how game UIs are designed.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZmYHpULbuN4ovLr-1GGa8a6Z-W85Nk=
k%3DmUMrf0vZs4bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZmYHpULb=
uN4ovLr-1GGa8a6Z-W85Nkk%3DmUMrf0vZs4bw%40mail.gmail.com</a>.<br />

--047d7b3a9b3a9aa6c4052dc8e25e--

.

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

On Fri, Mar 11, 2016 at 11:44 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> There's nothing wrong with sequencing; to express a program being able to
> employ sequencing is great. But we need to be able to express its absence
> as well.
>

No, we don't, unless we're writing concurrent programs.  No programmer
(with probability 0) has ever wished, when writing code that does several
things, that there was a way to tell the programming system that the order
of those things doesn't matter.  It's a made-up need designed to convince
people that the order of evaluation of expressions should not be specified.


> I really don't follow. Assembler is far less amenable to optimization than
> high level languages.
>
Optimizers manipulate assembly language by applying permissible
transformations.  Humans can apply a wider set of transformations based on
global knowledge of the domain, so humans writing assembly language can
produce better code than optimizers.  So choosing to program in high-level
languages rather than in assembler is choosing to trade performance for
convenience and expressiveness.


> > The freedom of compilers is unimportant.  Compilers must already follow
> thousands of nitpicky
> > rules which constrain what they do.
>
> That makes their remaining freedom more important, not less.
>

No, it does not.  It is easy to find examples where giving the compiler the
freedom to act as if undefined behavior never occurs leads to terrible
problems with compiled code, such as security checks being eliminated.
 (Such code is "bad" only because the designers of the language made bad
choices about what such code should do, here with respect to signed integer
overflow.)

A computer program is a means for specifying the behavior of a computer.  A
compiler is a computer program for translating such a specification into a
form the computer can use.  To the extent that the compiler does not honor
the intent of the program because of an obscure point in the language it
compiles, the compiler and the language are broken, because the computer
will fail to behave in the way the programmer intended it to behave.

> > Your argument about decreasing expressiveness of the
> > language is wrong; were you correct, a language standard that said that
> all programs have
> > undefined behavior and the standard imposes no requirements on them
> would have the maximum
> > possible expressiveness.  But such a language would be useless, and no
> one (except perhaps
> > possibly you) would declare such a language "expressive".
>
> That's not what we mean by expressiveness.
>
> > On the contrary, specifying order of evaluation increases expressiveness
> because "expressiveness"
> > is the property of assigning meaning to writing, and specifying order
> adds meaning in a context where
> > the order in which things happen is manifestly important.
>
> That's also not what we mean by expressiveness. Expressive power is a
> measure of the breadth of ideas that can be represented and communicated in
> a language. C++ with a defined order of evaluation cannot express the idea
> of indeterminate sequencing of evaluation of operands, so is less
> expressive.
>

C++ with an unspecified order of evaluation cannot express the idea that
the subparts of an expression are evaluated in a specific order.  That is
more valuable.  As I claim above, the probability that any programmer
wishes to express indeterminate sequencing is vanishingly small; that
notion is invented only to argue against fixing 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/CAHSYqdbm%2BrdFZjrsVO-VdS5secCGOn%3DewWNEuSZTjH6xfoR33Q%40mail.gmail.com.

--001a1143fae08331c6052dc9717c
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, Mar 11, 2016 at 11:44 AM, &#39;Edward Catmur&#39; via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<=
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"><span class=3D"">
</span><p dir=3D"ltr">There&#39;s nothing wrong with sequencing; to express=
 a program being able to employ sequencing is great. But we need to be able=
 to express its absence as well.</p></div></blockquote><div><br></div><div>=
No, we don&#39;t, unless we&#39;re writing concurrent programs.=C2=A0 No pr=
ogrammer (with probability 0) has ever wished, when writing code that does =
several things, that there was a way to tell the programming system that th=
e order of those things doesn&#39;t matter.=C2=A0 It&#39;s a made-up need d=
esigned to convince people that the order of evaluation of expressions shou=
ld not be specified.</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=
"><p dir=3D"ltr"> </p><span class=3D"">
<p dir=3D"ltr">I really don&#39;t follow. Assembler is far less amenable to=
 optimization than high level languages.<br></p></span></div></blockquote><=
div>Optimizers manipulate assembly language by applying permissible transfo=
rmations.=C2=A0 Humans can apply a wider set of transformations based on gl=
obal knowledge of the domain, so humans writing assembly language can produ=
ce better code than optimizers.=C2=A0 So choosing to program in high-level =
languages rather than in assembler is choosing to trade performance for con=
venience and expressiveness.<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"lt=
r"><span class=3D""><p dir=3D"ltr"></p></span><span class=3D"">
<p dir=3D"ltr">&gt; The freedom of compilers is unimportant.=C2=A0 Compiler=
s must already follow thousands of nitpicky<br>
&gt; rules which constrain what they do.=C2=A0</p>
</span><p dir=3D"ltr">That makes their remaining freedom more important, no=
t less.</p></div></blockquote><div><br>No, it does not.=C2=A0 It is easy to=
 find examples where giving the compiler the freedom to act as if undefined=
 behavior never occurs leads to terrible problems with compiled code, such =
as security checks being eliminated. =C2=A0(Such code is &quot;bad&quot; on=
ly because the designers of the language made bad choices about what such c=
ode should do, here with respect to signed integer overflow.)<br><br>A comp=
uter program is a means for specifying the behavior of a computer.=C2=A0 A =
compiler is a computer program for translating such a specification into a =
form the computer can use.=C2=A0 To the extent that the compiler does not h=
onor the intent of the program because of an obscure point in the language =
it compiles, the compiler and the language are broken, because the computer=
 will fail to behave in the way the programmer intended it to behave.</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;p=
adding-left:1ex"><div dir=3D"ltr"><p dir=3D"ltr"> </p><span class=3D"">
<p dir=3D"ltr">&gt; Your argument about decreasing expressiveness of=C2=A0t=
he<br>
&gt; language is wrong; were you correct, a language standard that said tha=
t all programs have<br>
&gt; undefined behavior and the standard imposes no requirements on them wo=
uld have the maximum<br>
&gt; possible expressiveness.=C2=A0 But such a language would be useless, a=
nd no one (except perhaps<br>
&gt; possibly you) would declare such a language &quot;expressive&quot;.</p=
>
</span><p dir=3D"ltr">That&#39;s not what we mean by expressiveness. </p><s=
pan class=3D"">
<p dir=3D"ltr">&gt; On the contrary, specifying order of evaluation increas=
es expressiveness because &quot;expressiveness&quot;<br>
&gt; is the property of assigning meaning to writing, and specifying order =
adds meaning in a context where<br>
&gt; the order in which things happen is manifestly important.</p>
</span><p dir=3D"ltr">That&#39;s also not what we mean by expressiveness. E=
xpressive power is a measure of the breadth of ideas that can be represente=
d and communicated in a language. C++ with a defined order of evaluation ca=
nnot express the idea of indeterminate sequencing of evaluation of operands=
, so is less expressive.</p></div></blockquote><div><br>C++ with an unspeci=
fied order of evaluation cannot express the idea that the subparts of an ex=
pression are evaluated in a specific order.=C2=A0 That is more valuable.=C2=
=A0 As I claim above, the probability that any programmer wishes to express=
 indeterminate sequencing is vanishingly small; that notion is invented onl=
y to argue against fixing 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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbm%2BrdFZjrsVO-VdS5secCGOn%3De=
wWNEuSZTjH6xfoR33Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbm%2Br=
dFZjrsVO-VdS5secCGOn%3DewWNEuSZTjH6xfoR33Q%40mail.gmail.com</a>.<br />

--001a1143fae08331c6052dc9717c--

.

On sexta-feira, 11 de mar=C3=A7o de 2016 12:41:19 PST Hyman Rosen wrote:
> A computer program is a means for specifying the behavior of a computer. =
 A
> compiler is a computer program for translating such a specification into =
a
> form the computer can use.  To the extent that the compiler does not hono=
r
> the intent of the program because of an obscure point in the language it
> compiles, the compiler and the language are broken, because the computer
> will fail to behave in the way the programmer intended it to behave.

There's a subjective point here which is the "obscure point in the language=
".=20
What's obscure to some people may not be so to others, and this changes ove=
r=20
time.

In the example you gave (signed integer overflow), it's also easy to constr=
uct=20
a case where the programmer *did* mean that no overflow will happen and the=
=20
compiler should optimise any checks for overflows out. We have those in Qt =
and=20
we like that the compiler does not add any unnecessary checks, as we've=20
already done them ourselves somewhere that the compiler couldn't see.

-Wstrict-overflow is also the only warning we cannot completely suppress wi=
th=20
GCC.

--=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/11966380.M0Y21Hd5BE%40tjmaciei-mobl4.

.

On 11 March 2016 at 19:41, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> No, we don't, unless we're writing concurrent programs.  No programmer (with
> probability 0) has ever wished, when writing code that does several things,
> that there was a way to tell the programming system that the order of those
> things doesn't matter.  It's a made-up need designed to convince people that

The existence of LET* and PROG* forms in Common Lisp suggests
otherwise. Sure, those
forms are not completely without order, but they specifically state
that side-effects are
not visible in the individual assignment forms, so assignment forms
can run in whichever
form without affecting each other.

But hey, it's not like this whole discussion thread allows room for
"evidence" or "facts", so
never mind.

--
You received this message because you are 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/CAFk2RUYZO%2BjYcWrGVo-Z3HHVqGbgFPBfguv7n%2BsUx18bK79qfA%40mail.gmail.com.

.

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

In Common Lisp, function argument evaluation is strictly
left-to-right: 3.1.2.1.2.3
Function Forms
<http://www.lispworks.com/documentation/HyperSpec/Body/03_ababc.htm>.
In Scheme, the order is unspecified: 1.4.4 Procedure Call Syntax
<http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Procedure-Call-Syntax.html#Procedure-Call-Syntax>
..
So other languages appear to have the same argument going.

On Fri, Mar 11, 2016 at 2:42 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 11 March 2016 at 19:41, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> > No, we don't, unless we're writing concurrent programs.  No programmer
> (with
> > probability 0) has ever wished, when writing code that does several
> things,
> > that there was a way to tell the programming system that the order of
> those
> > things doesn't matter.  It's a made-up need designed to convince people
> that
>
> The existence of LET* and PROG* forms in Common Lisp suggests
> otherwise. Sure, those
> forms are not completely without order, but they specifically state
> that side-effects are
> not visible in the individual assignment forms, so assignment forms
> can run in whichever
> form without affecting each other.
>
> But hey, it's not like this whole discussion thread allows room for
> "evidence" or "facts", so
> never mind.
>
> --
> You received this message because you are 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/CAFk2RUYZO%2BjYcWrGVo-Z3HHVqGbgFPBfguv7n%2BsUx18bK79qfA%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/CAHSYqdbQEOQR098HOKfdiE5FHen31qJkrEZywmHZ0FGt5eCLvg%40mail.gmail.com.

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

<div dir=3D"ltr">In Common Lisp, function argument evaluation is strictly l=
eft-to-right:=C2=A0<a href=3D"http://www.lispworks.com/documentation/HyperS=
pec/Body/03_ababc.htm">3.1.2.1.2.3 Function Forms</a>.<br>In Scheme, the or=
der is unspecified:=C2=A0<a href=3D"http://www.gnu.org/software/mit-scheme/=
documentation/mit-scheme-ref/Procedure-Call-Syntax.html#Procedure-Call-Synt=
ax">1.4.4 Procedure Call Syntax</a>.<br>So other languages appear to have t=
he same argument going.</div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Fri, Mar 11, 2016 at 2:42 PM, Ville Voutilainen <span dir=3D=
"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">=
ville.voutilainen@gmail.com</a>&gt;</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"><span class=3D"">On 11 March 2016 at 19:41, Hyman Rosen &lt;<a hre=
f=3D"mailto:hyman.rosen@gmail.com">hyman.rosen@gmail.com</a>&gt; wrote:<br>
&gt; No, we don&#39;t, unless we&#39;re writing concurrent programs.=C2=A0 =
No programmer (with<br>
&gt; probability 0) has ever wished, when writing code that does several th=
ings,<br>
&gt; that there was a way to tell the programming system that the order of =
those<br>
&gt; things doesn&#39;t matter.=C2=A0 It&#39;s a made-up need designed to c=
onvince people that<br>
<br>
</span>The existence of LET* and PROG* forms in Common Lisp suggests<br>
otherwise. Sure, those<br>
forms are not completely without order, but they specifically state<br>
that side-effects are<br>
not visible in the individual assignment forms, so assignment forms<br>
can run in whichever<br>
form without affecting each other.<br>
<br>
But hey, it&#39;s not like this whole discussion thread allows room for<br>
&quot;evidence&quot; or &quot;facts&quot;, so<br>
never mind.<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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/CAFk2RUYZO%2BjYcWrGVo-Z3HHVqGb=
gFPBfguv7n%2BsUx18bK79qfA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUY=
ZO%2BjYcWrGVo-Z3HHVqGbgFPBfguv7n%2BsUx18bK79qfA%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbQEOQR098HOKfdiE5FHen31qJkrEZy=
wmHZ0FGt5eCLvg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbQEOQR098H=
OKfdiE5FHen31qJkrEZywmHZ0FGt5eCLvg%40mail.gmail.com</a>.<br />

--001a1143d3b42ac651052dcc781a--

.

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

In Common Lisp, LET and LET* evaluate their initialization forms strictly
left-to-right: Special Operator LET, LET*
<http://www.lispworks.com/documentation/HyperSpec/Body/s_let_l.htm>.

On Fri, Mar 11, 2016 at 2:42 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 11 March 2016 at 19:41, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> > No, we don't, unless we're writing concurrent programs.  No programmer
> (with
> > probability 0) has ever wished, when writing code that does several
> things,
> > that there was a way to tell the programming system that the order of
> those
> > things doesn't matter.  It's a made-up need designed to convince people
> that
>
> The existence of LET* and PROG* forms in Common Lisp suggests
> otherwise. Sure, those
> forms are not completely without order, but they specifically state
> that side-effects are
> not visible in the individual assignment forms, so assignment forms
> can run in whichever
> form without affecting each other.
>
> But hey, it's not like this whole discussion thread allows room for
> "evidence" or "facts", so
> never mind.
>
> --
> You received this message because you are 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/CAFk2RUYZO%2BjYcWrGVo-Z3HHVqGbgFPBfguv7n%2BsUx18bK79qfA%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/CAHSYqda%2BJJVsdhgUWicLxG5Ofg8LvgCc5sdCqirpq-%2BHzdy_sw%40mail.gmail.com.

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

<div dir=3D"ltr">In Common Lisp, LET and LET* evaluate their initialization=
 forms strictly left-to-right:=C2=A0<a href=3D"http://www.lispworks.com/doc=
umentation/HyperSpec/Body/s_let_l.htm">Special Operator LET, LET*</a>.</div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Mar 11, =
2016 at 2:42 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:=
ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.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"><span class=3D"">On=
 11 March 2016 at 19:41, Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen@gmai=
l.com">hyman.rosen@gmail.com</a>&gt; wrote:<br>
&gt; No, we don&#39;t, unless we&#39;re writing concurrent programs.=C2=A0 =
No programmer (with<br>
&gt; probability 0) has ever wished, when writing code that does several th=
ings,<br>
&gt; that there was a way to tell the programming system that the order of =
those<br>
&gt; things doesn&#39;t matter.=C2=A0 It&#39;s a made-up need designed to c=
onvince people that<br>
<br>
</span>The existence of LET* and PROG* forms in Common Lisp suggests<br>
otherwise. Sure, those<br>
forms are not completely without order, but they specifically state<br>
that side-effects are<br>
not visible in the individual assignment forms, so assignment forms<br>
can run in whichever<br>
form without affecting each other.<br>
<br>
But hey, it&#39;s not like this whole discussion thread allows room for<br>
&quot;evidence&quot; or &quot;facts&quot;, so<br>
never mind.<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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/CAFk2RUYZO%2BjYcWrGVo-Z3HHVqGb=
gFPBfguv7n%2BsUx18bK79qfA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUY=
ZO%2BjYcWrGVo-Z3HHVqGbgFPBfguv7n%2BsUx18bK79qfA%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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqda%2BJJVsdhgUWicLxG5Ofg8LvgCc5s=
dCqirpq-%2BHzdy_sw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda%2BJJ=
VsdhgUWicLxG5Ofg8LvgCc5sdCqirpq-%2BHzdy_sw%40mail.gmail.com</a>.<br />

--001a1143fae0d5bc2a052dcc86e4--

.

On 11 March 2016 at 23:22, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> In Common Lisp, LET and LET* evaluate their initialization forms strictly
> left-to-right: Special Operator LET, LET*.

LET doesn't perform the bindings of the initialization forms in
left-to-right order.
LET* does.

Which is quite related to having an unspecified evaluation order,
since the bindings made by LET
are not seen in subsequent init-forms. So your claim that
"No programmer (with probability 0) has ever wished, when writing code
that does several things,
that there was a way to tell the programming system that the order of those
things doesn't matter."
doesn't seem correct to me.

That is not an argument for unspecified evaluation order, I'm just
pointing out there are existing
examples where programmers thought that they needed unspecified order,
and there are languages
that provide both unspecified and specified evaluation 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/CAFk2RUbBxawKTiQSem3joBD44Xp%3DbDVKZu5feq13euBMGsUJpQ%40mail.gmail.com.

.

--047d7bdca440e52ad8052dcde0a7
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 11, 2016 at 5:41 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> Optimizers manipulate assembly language by applying permissible
> transformations.  Humans can apply a wider set of transformations based on
> global knowledge of the domain, so humans writing assembly language can
> produce better code than optimizers.  So choosing to program in high-level
> languages rather than in assembler is choosing to trade performance for
> convenience and expressiveness.
>

Optimizations at the assembly language level are a small subset of the
transformations that a compiler can perform. Transformations above that
level require knowledge of the programming language semantics, so
expressiveness and performance arise from the extent to which the
programming language leaves aspects of the translation unspecified. The
idea that humans can write better machine code than an optimizing compiler
has been obsolete for decades.


> C++ with an unspecified order of evaluation cannot express the idea that
> the subparts of an expression are evaluated in a specific order.  That is
> more valuable.  As I claim above, the probability that any programmer
> wishes to express indeterminate sequencing is vanishingly small; that
> notion is invented only to argue against fixing the language.
>
> It is a trivial operation to transform a C++ expression into one that has
the same semantics with the addition of a specific order of evaluation.
That indicates that (and certainly under Felleisen's formalism[1] proves
that) the expressive power of C++ with a specific order of evaluation is no
greater than that of C++ with unspecified order of evaluation.

1. On the Expressive Power of Programming Languages, Matthias Felleisen
(1990)

--
You received this message because you are 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/CAJnLdObbphZA%2BEXzbhhdt_pKWB805VB%2BDEf8%2B%2BbtP6ucGy_JPA%40mail.gmail.com.

--047d7bdca440e52ad8052dcde0a7
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, Mar 11, 2016 at 5:41 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt=
;</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"><div>Optimizers manipulate assembly languag=
e by applying permissible transformations.=C2=A0 Humans can apply a wider s=
et of transformations based on global knowledge of the domain, so humans wr=
iting assembly language can produce better code than optimizers.=C2=A0 So c=
hoosing to program in high-level languages rather than in assembler is choo=
sing to trade performance for convenience and expressiveness.<br></div></di=
v></div></div></blockquote><div><br></div><div>Optimizations at the assembl=
y language level are a small subset of the transformations that a compiler =
can perform. Transformations above that level require knowledge of the prog=
ramming language semantics, so expressiveness and performance arise from th=
e extent to which the programming language leaves aspects of the translatio=
n unspecified. The idea that humans can write better machine code than an o=
ptimizing compiler has been obsolete for decades.</div><div>=C2=A0</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"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div>C++ with an unspecified order of evaluation cannot express t=
he idea that the subparts of an expression are evaluated in a specific orde=
r.=C2=A0 That is more valuable.=C2=A0 As I claim above, the probability tha=
t any programmer wishes to express indeterminate sequencing is vanishingly =
small; that notion is invented only to argue against fixing the language.</=
div></div></div></div><span class=3D""><font color=3D"#888888">

<p></p></font></span></blockquote></div></div><div class=3D"gmail_extra">It=
 is a trivial operation to transform a C++ expression into one that has the=
 same semantics with the addition of a specific order of evaluation. That i=
ndicates that (and certainly under Felleisen&#39;s formalism[1] proves that=
) the expressive power of C++ with a specific order of evaluation is no gre=
ater than that of C++ with unspecified order of evaluation.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">1.=C2=A0On the Expres=
sive Power of Programming Languages, Matthias Felleisen (1990)</div></div>

<p></p>

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

--047d7bdca440e52ad8052dcde0a7--

.

> This means that the notion that such code will be weeded out by review is=
 fatally flawed; neither the authors nor the reviewers will see the problem=
..  At best, with multiple increments, reviewers may feel some suspicion bec=
ause they may recall some folklore that such code is bad.  When the code in=
volves multiple function calls and unspecified rather than undefined behavi=
or, I doubt that many reviewers will ever notice.

As a reviewer, my attention rarely is on evaluation order anyway. Because, =
as you say, EO rarely is an issue.

But I=E2=80=99m not likely to spot it for another reason, namely, because t=
he code has already passed its tests before it gets to review, and coverage=
 will show that the relevant lines of code were executed. So, the expressio=
n looks harmless, it was tested, and it produces the correct result. Everyb=
ody move along, nothing to see here=E2=80=A6

A really interesting experiment would be to take a compiler and modify it t=
o dump core (or maybe spew out errors at run time) whenever it comes across=
 an expression with undefined evaluation order. Then go and, say, compile a=
 bunch of large systems from source and try to use them for a while to see =
how many things break. I bet the results would be interesting.

Michi.

--=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/7905D8AC-3032-4D7D-A886-49A6AA57D2DA%40canonical=
..com.

.

------=_Part_3491_805849763.1457752884155
Content-Type: multipart/alternative;
 boundary="----=_Part_3492_1840341416.1457752884156"

------=_Part_3492_1840341416.1457752884156
Content-Type: text/plain; charset=UTF-8

For those that haven't seen this yet:

http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeting/

Evolution also approved the following features that were not voted in at
this meeting, but are currently on track for possible approval for C++17 at
our next meeting in June for inclusion in the C++17 international comment
ballot

Defining the order of expression evaluation to reduce portability and
usability bugs.

--
You received this message because you are 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/be456c0e-c79d-43f4-a24d-527c2028857a%40isocpp.org.

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

<div dir=3D"ltr">For those that haven&#39;t seen this yet:<br><br>http://he=
rbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeting/<br><br>=
Evolution also approved the following features that were not voted in at th=
is meeting, but are currently on track for possible approval for C++17 at o=
ur next meeting in June for inclusion in the C++17 international comment ba=
llot<div><br>Defining the order of expression evaluation to reduce portabil=
ity and usability bugs.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/be456c0e-c79d-43f4-a24d-527c2028857a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/be456c0e-c79d-43f4-a24d-527c2028857a=
%40isocpp.org</a>.<br />

------=_Part_3492_1840341416.1457752884156--
------=_Part_3491_805849763.1457752884155--

.

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

2016-03-12 6:51 GMT+03:30 Greg Marr <gregmmarr@gmail.com>:

> For those that haven't seen this yet:
>
>
> http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeti=
ng/
>
> Evolution also approved the following features that were not voted in at
> this meeting, but are currently on track for possible approval for C++17 =
at
> our next meeting in June for inclusion in the C++17 international comment
> ballot
>
> Defining the order of expression evaluation to reduce portability and
> usability bugs.
>

=E2=80=8BInteresting read!!!
By the way, has anybody mentioned that the most natural order might be that
of combining operators with operands(ie rules of associativity and
precedence)?=E2=80=8B

=E2=80=8Bregards,
FM.=E2=80=8B



--=20
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

--=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/CALDL7dGV8XZ%2BNB0mFRorNrNFC%3DLi%2BJm0mj6Rmj65x=
-v7JyAxiA%40mail.gmail.com.

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

<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:arial na=
rrow,sans-serif;font-size:large"><br></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote"><div dir=3D"ltr">2016-03-12 6:51 GMT+03:30 Greg M=
arr <span dir=3D"ltr">&lt;<a href=3D"mailto:gregmmarr@gmail.com" target=3D"=
_blank">gregmmarr@gmail.com</a>&gt;</span>:</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">For those that haven&#39;t seen this yet:<br><br><a h=
ref=3D"http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-=
meeting/" target=3D"_blank">http://herbsutter.com/2016/03/11/trip-report-wi=
nter-iso-c-standards-meeting/</a><br><br>Evolution also approved the follow=
ing features that were not voted in at this meeting, but are currently on t=
rack for possible approval for C++17 at our next meeting in June for inclus=
ion in the C++17 international comment ballot<div><br>Defining the order of=
 expression evaluation to reduce portability and usability bugs.</div></div=
></blockquote></div><div class=3D"gmail_extra" dir=3D"ltr"><br></div><div d=
ir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:&#39;arial nar=
row&#39;,sans-serif;font-size:large">=E2=80=8BInteresting read!!!=C2=A0</di=
v><div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,=
sans-serif;font-size:large">By the way, has anybody mentioned that the most=
 natural order might be that of combining operators with operands(ie rules =
of associativity and precedence)?=E2=80=8B</div><div class=3D"gmail_default=
" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><=
br></div><div class=3D"gmail_default" style=3D"font-family:&#39;arial narro=
w&#39;,sans-serif;font-size:large">=E2=80=8Bregards,</div><div class=3D"gma=
il_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-siz=
e:large">FM.=E2=80=8B</div><br><br clear=3D"all"></div><div><br></div>-- <b=
r><div class=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how=
 am I supposed to end the twisted road of=C2=A0 your hair in such a dark ni=
ght??<br>unless the candle of your face does shed some light upon my way!!!=
<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dGV8XZ%2BNB0mFRorNrNFC%3DLi%2BJ=
m0mj6Rmj65x-v7JyAxiA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dGV8X=
Z%2BNB0mFRorNrNFC%3DLi%2BJm0mj6Rmj65x-v7JyAxiA%40mail.gmail.com</a>.<br />

--001a114a869684523e052dd56001--

.

--047d7b2e47c85ed7b5052ddd1e04
Content-Type: text/plain; charset=UTF-8

On 12 Mar 2016 00:51, "Michi Henning" <michi.henning@canonical.com> wrote:
>
>
> A really interesting experiment would be to take a compiler and modify it
to dump core (or maybe spew out errors at run time) whenever it comes
across an expression with undefined evaluation order. Then go and, say,
compile a bunch of large systems from source and try to use them for a
while to see how many things break. I bet the results would be interesting.

As has been noted above, compilers already warn for undefined behavior
arising from unsequenced modifications to the same variable. So you would
be looking for undefined behavior arising from aliasing; I strongly suspect
you wouldn't find much, as in practice aliasing is pretty rare.

Not to say that it wouldn't be a valuable exercise, but if you have the
time to do so it would probably be more useful to modify the compiler to
implement a reversed order of evaluation from its norm and observe that
same large system for harmful deviations in 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/CAJnLdOa-%2Bfn-DxsszV_BBZn0shW9-EMuydAQCBdFuZ6qW3iTHA%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 12 Mar 2016 00:51, &quot;Michi Henning&quot; &lt;<a href=3D"mailto:michi=
..henning@canonical.com">michi.henning@canonical.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; A really interesting experiment would be to take a compiler and modify=
 it to dump core (or maybe spew out errors at run time) whenever it comes a=
cross an expression with undefined evaluation order. Then go and, say, comp=
ile a bunch of large systems from source and try to use them for a while to=
 see how many things break. I bet the results would be interesting.</p>
<p dir=3D"ltr">As has been noted above, compilers already warn for undefine=
d behavior arising from unsequenced modifications to the same variable. So =
you would be looking for undefined behavior arising from aliasing; I strong=
ly suspect you wouldn&#39;t find much, as in practice aliasing is pretty ra=
re.</p>
<p dir=3D"ltr">Not to say that it wouldn&#39;t be a valuable exercise, but =
if you have the time to do so it would probably be more useful to modify th=
e compiler to implement a reversed order of evaluation from its norm and ob=
serve that same large system for harmful deviations in behavior. </p>

<p></p>

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

--047d7b2e47c85ed7b5052ddd1e04--

.

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

On Mar 11, 2016 5:17 PM, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:
>
> On 11 March 2016 at 23:22, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> > In Common Lisp, LET and LET* evaluate their initialization forms
strictly
> > left-to-right: Special Operator LET, LET*.
>
> LET doesn't perform the bindings of the initialization forms in
> left-to-right order.
> LET* does.
>
> Which is quite related to having an unspecified evaluation order,
> since the bindings made by LET
> are not seen in subsequent init-forms. So your claim that
> "No programmer (with probability 0) has ever wished, when writing code.
> that does several things,
> that there was a way to tell the programming system that the order of
those
> things doesn't matter."
> doesn't seem correct to me.
>
> That is not an argument for unspecified evaluation order, I'm just
> pointing out there are existing
> examples where programmers thought that they needed unspecified order,
> and there are languages
> that provide both unspecified and specified evaluation order.

But I showed you the page in the Common Lisp specification where it says
explicitly that for LET the initialization forms are evaluated
left-to-right then all the bindings are done at once.  There is no
unspecified order here at all.

It may be that in the more functional languages, where side effects are
rarer, the designers thought it would be clever to allow for a kind of
parallelism.  But Common Lisp did away with that, and if I had to guess
why, I would say it's for the same reasons I claim here.

--
You received this message because you are 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/CAHSYqdYMJW9Q4xE-LW0AiuRFh_FvG0upjZ1Ji_yHctfPycwHCg%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On Mar 11, 2016 5:17 PM, &quot;Ville Voutilainen&quot; &lt;<a href=3D"mailt=
o:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:<b=
r>
&gt;<br>
&gt; On 11 March 2016 at 23:22, Hyman Rosen &lt;<a href=3D"mailto:hyman.ros=
en@gmail.com">hyman.rosen@gmail.com</a>&gt; wrote:<br>
&gt; &gt; In Common Lisp, LET and LET* evaluate their initialization forms =
strictly<br>
&gt; &gt; left-to-right: Special Operator LET, LET*.<br>
&gt;<br>
&gt; LET doesn&#39;t perform the bindings of the initialization forms in<br=
>
&gt; left-to-right order.<br>
&gt; LET* does.<br>
&gt;<br>
&gt; Which is quite related to having an unspecified evaluation order,<br>
&gt; since the bindings made by LET<br>
&gt; are not seen in subsequent init-forms. So your claim that<br>
&gt; &quot;No programmer (with probability 0) has ever wished, when writing=
 code.<br>
&gt; that does several things,<br>
&gt; that there was a way to tell the programming system that the order of =
those<br>
&gt; things doesn&#39;t matter.&quot;<br>
&gt; doesn&#39;t seem correct to me.<br>
&gt;<br>
&gt; That is not an argument for unspecified evaluation order, I&#39;m just=
<br>
&gt; pointing out there are existing<br>
&gt; examples where programmers thought that they needed unspecified order,=
<br>
&gt; and there are languages<br>
&gt; that provide both unspecified and specified evaluation order.</p>
<p dir=3D"ltr">But I showed you the page in the Common Lisp specification w=
here it says explicitly that for LET the initialization forms are evaluated=
 left-to-right then all the bindings are done at once.=C2=A0 There is no un=
specified order here at all.</p>
<p dir=3D"ltr">It may be that in the more functional languages, where side =
effects are rarer, the designers thought it would be clever to allow for a =
kind of parallelism.=C2=A0 But Common Lisp did away with that, and if I had=
 to guess why, I would say it&#39;s for the same reasons I claim here.</p>

<p></p>

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

--001a11438a4e749be7052de3be28--

.

On 13 March 2016 at 03:04, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>> On 11 March 2016 at 23:22, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>> > In Common Lisp, LET and LET* evaluate their initialization forms
>> > strictly
>> > left-to-right: Special Operator LET, LET*.
>>
>> LET doesn't perform the bindings of the initialization forms in
>> left-to-right order.
>> LET* does.
>>
>> Which is quite related to having an unspecified evaluation order,
>> since the bindings made by LET
>> are not seen in subsequent init-forms. So your claim that
>> "No programmer (with probability 0) has ever wished, when writing code.
>> that does several things,
>> that there was a way to tell the programming system that the order of
>> those
>> things doesn't matter."
>> doesn't seem correct to me.
>>
>> That is not an argument for unspecified evaluation order, I'm just
>> pointing out there are existing
>> examples where programmers thought that they needed unspecified order,
>> and there are languages
>> that provide both unspecified and specified evaluation order.
>
> But I showed you the page in the Common Lisp specification where it says
> explicitly that for LET the initialization forms are evaluated left-to-right
> then all the bindings are done at once.  There is no unspecified order here
> at all.

All bindings are done "at once", but there's no unspecified order? The bindings
are done magically in parallel? Right there is your unspecified order
bit, should
you choose to accept to see 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/CAFk2RUbMigXY%2BM2cdFyrY7vKBe7qsdOqtBg4yySUqStjWGUcCg%40mail.gmail.com.

.

------=_Part_3860_618402576.1457891114868
Content-Type: multipart/alternative;
 boundary="----=_Part_3861_1728080674.1457891114869"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8811:50:40=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Mar 11, 2016 at 12:36 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>
>> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 =
UTC+8=E4=B8=8A=E5=8D=8812:20:43=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> 1.9 { Program execution }
>>> *If a side effect on a scalar object is unsequenced relative to either=
=20
>>> another side effect on the same scalar object or a value computation us=
ing=20
>>> the value of the same scalar object ... the behavior is undefined.*
>>>
>>> This statement contains multiple side effects (the ++category=20
>>> expressions) that are
>>> unsequenced with respect to each other.
>>> ...
>>
>> Your explanation is wrong. The side effect within a builtin *prefix *++=
=20
>> is sequenced before the value computation of that expression after CWG63=
7=20
>> <http://wg21.cmeerw.net/cwg/issue637> resolved. Value computation of=20
>> result different ++ expressions are chained by the overloaded << functio=
n=20
>> calls, thus they are sequenced indirectly by the rule of "sequenced befo=
re"=20
>> rule between function arguments and function body, and the transitive=20
>> property provided by the definition of "sequenced before" binary=20
>> relationship. These rules should also be in 1.9 IIRC.
>>
>> I should apologize that I did not read your smelly code carefully. Your=
=20
>> explanation is right if it was postfix ++ or in C++98/03.
>>
>
> I doubt that my explanation is wrong; I have a copy of a C++17 working=20
> draft (N4527) and I see nothing there that supports your theory.  A=20
> simplified version of my code is s.f(++i).f(++i).  If you believe that=20
> this is not undefined behavior, please quote the relevant portions of the=
=20
> standard that require the two appearances of ++i to be sequenced with=20
> respect to each other. (If you cannot, as I believe you will discover, th=
is=20
> will be yet more evidence of experts not understanding order of evaluatio=
n.)
>
> My fault. (Damn infix syntax sugar.) Transformed to S-expr:(<< (<< (<<=20
cout (++ i)) (++ i)) (++ i)), leaf nodes are not chained. Correction: still=
=20
UB due to unsequenced '++' on 'i' in different subexpressions. It is like i=
=20
=3D i++ =3D i++, not i =3D i++.
=20

> On a related note, your continuing characterization of such code as "bad"=
=20
> and "smelly" carries no weight with me.  The reason why such code is=20
> problematic is that the language definition is wrong.  If the language we=
re=20
> correct, this code would be fine, its purpose readily apparent and its=20
> functioning understood.  Attacking the code instead of the language is an=
=20
> excuse to maintain a flawed status quo and an attempt to sway people away=
=20
> from fixing it.
>
=20
This is proved bad to me since it messed AST and confused me :(
I don't believe changing those language will fix it because the root evil=
=20
is you're encouraging unconstrainted side effects. If you think this style=
=20
is fit for sequenced operations, go ahead. I'll always reject such code due=
=20
to lacking of (explicit enough) mark (like semicolon) to guarantee the=20
order. I prefer it to be ill-formed (with diagnostics). But anyway, this is=
=20
not the sufficient reason to drop the ability to express unsequenced=20
operations.


--=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/ab6e76c3-87cc-44e9-8f4b-01c59ff3bd84%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8811=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8811:50:40=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, Mar 11, 2016 at 12:36=
 AM, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"jAniyQA6BwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">frank...@gmail.com</a>&gt;</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">=E5=9C=A8 2016=E5=B9=
=B43=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=88=
12:20: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 soli=
d;padding-left:1ex"><span><div dir=3D"ltr"><div><div>1.9 { Program executio=
n }<div><i>If a side effect on a scalar object is unsequenced relative to e=
ither another side effect on the same scalar object or a value computation =
using the value of the same scalar object ... the behavior is undefined.</i=
></div><div><i><br></i></div><div>This statement contains multiple side eff=
ects (the ++category expressions) that are<br>unsequenced with respect to e=
ach other.</div></div></div></div></span>...</blockquote><div>Your explanat=
ion is wrong. The side effect within a builtin <i>prefix </i>++ is sequence=
d before the value computation of that expression after <a href=3D"http://w=
g21.cmeerw.net/cwg/issue637" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwg21.cmeerw=
..net%2Fcwg%2Fissue637\46sa\75D\46sntz\0751\46usg\75AFQjCNHVpRSpvius4hNImSWm=
Qrn5qUj7Kw&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google=
..com/url?q\75http%3A%2F%2Fwg21.cmeerw.net%2Fcwg%2Fissue637\46sa\75D\46sntz\=
0751\46usg\75AFQjCNHVpRSpvius4hNImSWmQrn5qUj7Kw&#39;;return true;">CWG637</=
a> resolved. Value computation of result different ++ expressions are chain=
ed by the overloaded &lt;&lt; function calls, thus they are sequenced indir=
ectly by the rule of &quot;sequenced before&quot; rule between function arg=
uments and function body, and the transitive property provided by the defin=
ition of &quot;sequenced before&quot; binary relationship. These rules shou=
ld also be in 1.9 IIRC.<br><br>I should apologize that I did not read your =
smelly code carefully. Your explanation is right if it was postfix ++ or in=
 C++98/03.</div></div></blockquote><div><br>I doubt that my explanation is =
wrong; I have a copy of a C++17 working draft (N4527) and I see nothing the=
re that supports your theory.=C2=A0 A simplified version of my code is <fon=
t face=3D"monospace, monospace">s.f(++i).f(++i)</font>.=C2=A0 If you believ=
e that this is not undefined behavior, please quote the relevant portions o=
f the standard that require the two appearances of <font face=3D"monospace,=
 monospace">++i</font><font face=3D"arial, helvetica, sans-serif"> </font>t=
o be sequenced with respect to each other. (If you cannot, as I believe you=
 will discover, this will be yet more evidence of experts not understanding=
 order of evaluation.)<br><br></div></div></div></div></blockquote><div>My =
fault. (Damn infix syntax sugar.) Transformed to S-expr:(&lt;&lt; (&lt;&lt;=
 (&lt;&lt; cout (++ i)) (++ i)) (++ i)), leaf nodes are not chained. Correc=
tion: still UB due to unsequenced &#39;++&#39; on &#39;i&#39; in different =
subexpressions. It is like i =3D i++ =3D i++, not i =3D i++.<br>=C2=A0<br><=
/div><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><di=
v class=3D"gmail_quote"><div>On a related note, your continuing characteriz=
ation of such code as &quot;bad&quot; and &quot;smelly&quot; carries no wei=
ght with me.=C2=A0 The reason why such code is problematic is that the lang=
uage definition is wrong.=C2=A0 If the language were correct, this code wou=
ld be fine, its purpose readily apparent and its functioning understood.=C2=
=A0 Attacking the code instead of the language is an excuse to maintain a f=
lawed status quo and an attempt to sway people away from fixing it.</div></=
div></div></div></blockquote><div>=C2=A0<br>This is proved bad to me since =
it messed AST and confused me :(<br>I don&#39;t believe changing those lang=
uage will fix it because the root evil is you&#39;re encouraging unconstrai=
nted side effects. If you think this style is fit for sequenced operations,=
 go ahead. I&#39;ll always reject such code due to lacking of (explicit eno=
ugh) mark (like semicolon) to guarantee the order. I prefer it to be ill-fo=
rmed (with diagnostics). But anyway, this is not the sufficient reason to d=
rop the ability to express unsequenced operations.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ab6e76c3-87cc-44e9-8f4b-01c59ff3bd84%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab6e76c3-87cc-44e9-8f4b-01c59ff3bd84=
%40isocpp.org</a>.<br />

------=_Part_3861_1728080674.1457891114869--
------=_Part_3860_618402576.1457891114868--

.

------=_Part_3846_273368220.1457893211978
Content-Type: multipart/alternative;
 boundary="----=_Part_3847_195347594.1457893211978"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8B=E5=8D=883:55:56=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> 2016-03-12 6:51 GMT+03:30 Greg Marr <greg...@gmail.com <javascript:>>:
>
>> For those that haven't seen this yet:
>>
>>
>> http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meet=
ing/
>>
>> Evolution also approved the following features that were not voted in at=
=20
>> this meeting, but are currently on track for possible approval for C++17=
 at=20
>> our next meeting in June for inclusion in the C++17 international commen=
t=20
>> ballot
>>
>> Defining the order of expression evaluation to reduce portability and=20
>> usability bugs.
>>
>
> =E2=80=8BInteresting read!!!=20
> By the way, has anybody mentioned that the most natural order might be=20
> that of combining operators with operands(ie rules of associativity and=
=20
> precedence)?=E2=80=8B
>
> Most natural? Either forget all those operators and operands, pretending=
=20
you are writing natural language, and let the compiler to do NLP; or use=20
some other writing system to make the need of associativity and precedence=
=20
away, specifically, without infix expressions, to get the simplest set of=
=20
order rules. All not feasible in C++. Relying on "rules of associativity=20
and precedence" is far from "natural" for users. Few people will remember=
=20
all those rules correctly. Also note "associativity and precedence" needs=
=20
some additional wording in the standard.

> =E2=80=8Bregards,
> FM.=E2=80=8B
>
>
>
> --=20
> how am I supposed to end the twisted road of  your hair in such a dark=20
> night??
> unless the candle of your face does shed some light upon my way!!!
>

--=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/6cd517c1-3bb2-47d4-a9cc-2ff8c2211384%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8812=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8B=E5=8D=883:55:56=EF=BC=8CFarid Mehrabi=
=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"rtl"><div style=3D"font-family:arial narrow,sans-serif;font-size:l=
arge"><br></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">2016-0=
3-12 6:51 GMT+03:30 Greg Marr <span dir=3D"ltr">&lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"dMAjh61uBwAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">greg...@gmail.com</a>&gt;</s=
pan>:</div><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">For those that h=
aven&#39;t seen this yet:<br><br><a href=3D"http://herbsutter.com/2016/03/1=
1/trip-report-winter-iso-c-standards-meeting/" target=3D"_blank" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3=
A%2F%2Fherbsutter.com%2F2016%2F03%2F11%2Ftrip-report-winter-iso-c-standards=
-meeting%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFZ3B3a9QEjcfgwYx8CEw1gJTtchA=
&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q=
\75http%3A%2F%2Fherbsutter.com%2F2016%2F03%2F11%2Ftrip-report-winter-iso-c-=
standards-meeting%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFZ3B3a9QEjcfgwYx8CE=
w1gJTtchA&#39;;return true;">http://herbsutter.com/2016/03/<wbr>11/trip-rep=
ort-winter-iso-c-<wbr>standards-meeting/</a><br><br>Evolution also approved=
 the following features that were not voted in at this meeting, but are cur=
rently on track for possible approval for C++17 at our next meeting in June=
 for inclusion in the C++17 international comment ballot<div><br>Defining t=
he order of expression evaluation to reduce portability and usability bugs.=
</div></div></blockquote></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">=
<div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large=
">=E2=80=8BInteresting read!!!=C2=A0</div><div style=3D"font-family:&#39;ar=
ial narrow&#39;,sans-serif;font-size:large">By the way, has anybody mention=
ed that the most natural order might be that of combining operators with op=
erands(ie rules of associativity and precedence)?=E2=80=8B</div><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></di=
v></div></div></div></blockquote><div>Most natural? Either forget all those=
 operators and operands, pretending you are writing natural language, and l=
et the compiler to do NLP; or use some other writing system to make the nee=
d of <span class=3D"op_dict3_font24 op_dict3_marginRight">associativity </s=
pan>and precedence away, specifically, without infix expressions, to get th=
e simplest set of order rules. All not feasible in C++. Relying on &quot;ru=
les of <span class=3D"op_dict3_font24 op_dict3_marginRight">associativity a=
nd precedence&quot; is far from &quot;natural&quot; for users. Few people w=
ill remember all those rules correctly. Also note &quot;associativity and p=
recedence&quot; needs some additional wording in the standard.</span><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"rtl"><div><div=
 dir=3D"ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;fo=
nt-size:large"></div><div style=3D"font-family:&#39;arial narrow&#39;,sans-=
serif;font-size:large">=E2=80=8Bregards,</div><div style=3D"font-family:&#3=
9;arial narrow&#39;,sans-serif;font-size:large">FM.=E2=80=8B</div><br><br c=
lear=3D"all"></div><div><br></div>-- <br><div><div dir=3D"rtl"><div><div di=
r=3D"ltr">how am I supposed to end the twisted road of=C2=A0 your hair in s=
uch a dark night??<br>unless the candle of your face does shed some light u=
pon my way!!!<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6cd517c1-3bb2-47d4-a9cc-2ff8c2211384%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6cd517c1-3bb2-47d4-a9cc-2ff8c2211384=
%40isocpp.org</a>.<br />

------=_Part_3847_195347594.1457893211978--
------=_Part_3846_273368220.1457893211978--

.

On 2016-03-12 05:22, Hyman Rosen wrote:
>
> Even very experienced C++ programmers do not notice problems with
> undefined behavior due to order of evaluation, for two reasons.  First,
> they do not remember that order of evaluation is an issue, since most of
> the time it is not, and they do not know or remember the rules governing
> it.  Second, the code communicates its intent so strongly that it is
> psychologically difficult to accept that it does not do exactly what it
> appears to.  Recall how novel it was to accept that f(new T, new T)
> could leak memory even when the parameters were smart pointers.
>   (Another nail in the coffin for unspecified order, papered over with
> more accusations of bad code - "don't use new directly".)
>
> This means that the notion that such code will be weeded out by review
> is fatally flawed; neither the authors nor the reviewers will see the
> problem.  At best, with multiple increments, reviewers may feel some
> suspicion because they may recall some folklore that such code is bad.
> When the code involves multiple function calls and unspecified rather
> than undefined behavior, I doubt that many reviewers will ever notice.

If anyone is interested in an actual real-world example...

Recently I wrote this bit of code:

     if (listen(fd, 10) == -1)
         throw system_error(errno, generic_category(), "listen(" +
to_string(fd) + ")");

This isn't a contrived example, it's actual code that almost made it
into production, written by an experienced C++ programmer (I've been
writing C++ for a living for more than 20 years). It wasn't until I
started seeing some funny-looking exceptions in testing that I realized
what I'd done wrong. If I hadn't been primed by following this thread I
might still be scratching my head :)

When this debate first showed up on this list I would have said I was
mildly on the "leave it undefined" side, but now I'm convinced that the
"define the order already and be done with it" side is right.

Ross Smith

--
You received this message because you are 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/56E5C69F.8020100%40otoy.com.

.

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

The to_string(), which can throw, is a bit scary too in this context...

2016-03-13 15:59 GMT-04:00 Ross Smith <ross.smith@otoy.com>:

> On 2016-03-12 05:22, Hyman Rosen wrote:
>
>>
>> Even very experienced C++ programmers do not notice problems with
>> undefined behavior due to order of evaluation, for two reasons.  First,
>> they do not remember that order of evaluation is an issue, since most of
>> the time it is not, and they do not know or remember the rules governing
>> it.  Second, the code communicates its intent so strongly that it is
>> psychologically difficult to accept that it does not do exactly what it
>> appears to.  Recall how novel it was to accept that f(new T, new T)
>> could leak memory even when the parameters were smart pointers.
>>   (Another nail in the coffin for unspecified order, papered over with
>> more accusations of bad code - "don't use new directly".)
>>
>> This means that the notion that such code will be weeded out by review
>> is fatally flawed; neither the authors nor the reviewers will see the
>> problem.  At best, with multiple increments, reviewers may feel some
>> suspicion because they may recall some folklore that such code is bad.
>> When the code involves multiple function calls and unspecified rather
>> than undefined behavior, I doubt that many reviewers will ever notice.
>>
>
> If anyone is interested in an actual real-world example...
>
> Recently I wrote this bit of code:
>
>     if (listen(fd, 10) == -1)
>         throw system_error(errno, generic_category(), "listen(" +
> to_string(fd) + ")");
>
> This isn't a contrived example, it's actual code that almost made it into
> production, written by an experienced C++ programmer (I've been writing C++
> for a living for more than 20 years). It wasn't until I started seeing some
> funny-looking exceptions in testing that I realized what I'd done wrong. If
> I hadn't been primed by following this thread I might still be scratching
> my head :)
>
> When this debate first showed up on this list I would have said I was
> mildly on the "leave it undefined" side, but now I'm convinced that the
> "define the order already and be done with it" side is right.
>
> Ross Smith
>
> --
> You received this message because you are 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/56E5C69F.8020100%40otoy.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/CAKiZDp0TYN73iqu%2BkVytPJBiKD_%3D4C5aJVBieL_2A2v3ZcoRBw%40mail.gmail.com.

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

<div dir=3D"ltr">The to_string(), which can throw, is a bit scary too in th=
is context...<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">2016-03-13 15:59 GMT-04:00 Ross Smith <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ross.smith@otoy.com" target=3D"_blank">ross.smith@otoy.com</a>&g=
t;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">On 2016-03-12 05:22, Hyman Ros=
en wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
Even very experienced C++ programmers do not notice problems with<br>
undefined behavior due to order of evaluation, for two reasons.=C2=A0 First=
,<br>
they do not remember that order of evaluation is an issue, since most of<br=
>
the time it is not, and they do not know or remember the rules governing<br=
>
it.=C2=A0 Second, the code communicates its intent so strongly that it is<b=
r>
psychologically difficult to accept that it does not do exactly what it<br>
appears to.=C2=A0 Recall how novel it was to accept that f(new T, new T)<br=
>
could leak memory even when the parameters were smart pointers.<br>
=C2=A0 (Another nail in the coffin for unspecified order, papered over with=
<br>
more accusations of bad code - &quot;don&#39;t use new directly&quot;.)<br>
<br>
This means that the notion that such code will be weeded out by review<br>
is fatally flawed; neither the authors nor the reviewers will see the<br>
problem.=C2=A0 At best, with multiple increments, reviewers may feel some<b=
r>
suspicion because they may recall some folklore that such code is bad.<br>
When the code involves multiple function calls and unspecified rather<br>
than undefined behavior, I doubt that many reviewers will ever notice.<br>
</blockquote>
<br>
If anyone is interested in an actual real-world example...<br>
<br>
Recently I wrote this bit of code:<br>
<br>
=C2=A0 =C2=A0 if (listen(fd, 10) =3D=3D -1)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 throw system_error(errno, generic_category(), &=
quot;listen(&quot; + to_string(fd) + &quot;)&quot;);<br>
<br>
This isn&#39;t a contrived example, it&#39;s actual code that almost made i=
t into production, written by an experienced C++ programmer (I&#39;ve been =
writing C++ for a living for more than 20 years). It wasn&#39;t until I sta=
rted seeing some funny-looking exceptions in testing that I realized what I=
&#39;d done wrong. If I hadn&#39;t been primed by following this thread I m=
ight still be scratching my head :)<br>
<br>
When this debate first showed up on this list I would have said I was mildl=
y on the &quot;leave it undefined&quot; side, but now I&#39;m convinced tha=
t the &quot;define the order already and be done with it&quot; side is righ=
t.<br>
<br>
Ross Smith<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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/56E5C69F.8020100%40otoy.com" rel=3D"n=
oreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/56E5C69F.8020100%40otoy.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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0TYN73iqu%2BkVytPJBiKD_%3D4C5a=
JVBieL_2A2v3ZcoRBw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0TYN73=
iqu%2BkVytPJBiKD_%3D4C5aJVBieL_2A2v3ZcoRBw%40mail.gmail.com</a>.<br />

--001a11436c72739b48052df6c79c--

.

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

On Sun, Mar 13, 2016 at 12:25 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> All bindings are done "at once", but there's no unspecified order? The
> bindings
> are done magically in parallel? Right there is your unspecified order
> bit, should you choose to accept to see it.
>

No user code runs between the left-to-right evaluation of the
initialization forms and the binding of the variables.  So yes, the
bindings happen all at once, in parallel, and there is no unspecified order
involved.  When there is actual unspecified order, as in C++, the effects
are observable.  The language does not specify the order, but the actual
program can observe what order the implementation chose.

--
You received this message because you are 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/CAHSYqdbvKpgUco%3D2hsT%3DTb4FPv7_Q4hKJyFRhB14G28oB%3DZGNg%40mail.gmail.com.

--001a1142419ab37a91052df9b93a
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, Mar 13, 2016 at 12:25 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All bind=
ings are done &quot;at once&quot;, but there&#39;s no unspecified order? Th=
e bindings<br>
are done magically in parallel? Right there is your unspecified order<br>
bit, should=C2=A0you choose to accept to see it.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">No user code runs b=
etween the left-to-right evaluation of the initialization forms and the bin=
ding of the variables.=C2=A0 So yes, the bindings happen all at once, in pa=
rallel, and there is no unspecified order involved.=C2=A0 When there is act=
ual unspecified order, as in C++, the effects are observable.=C2=A0 The lan=
guage does not specify the order, but the actual program can observe what o=
rder the implementation chose.</div></div>

<p></p>

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

--001a1142419ab37a91052df9b93a--

.

------=_Part_3909_720233086.1457927220747
Content-Type: multipart/alternative;
 boundary="----=_Part_3910_1891981396.1457927220747"

------=_Part_3910_1891981396.1457927220747
Content-Type: text/plain; charset=UTF-8

As an additional note, OCaml also has unspecified evaluation order which is
debatable: http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora029.html.
Many of points here are actually discussed decades ago:
http://osdir.com/ml/lang.caml.inria/2000-10/msg00014.html. Most contents
are more or less similar.
Remained 2 topics not deep discussed:
Automatic parallel evaluation. This optimization is even harder in general,
and it has to rely on as-if rules unconditionally in current C++ since no
abstract machine semantics provides such support. But it would likely gain
much more than plain arguments reordering.
Confusion for users using different languages. This is especially
significant for users switching between C and C++ daily, though I
personally don't care too much.

--
You received this message because you are 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/765dcb0f-595d-442b-9de9-aae68048cca8%40isocpp.org.

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

<div dir=3D"ltr">As an additional note, OCaml also has unspecified evaluati=
on order which
 is debatable:=20
http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora029.html.<br>Many
 of points here are actually discussed decades ago:=20
http://osdir.com/ml/lang.caml.inria/2000-10/msg00014.html. Most contents
 are more or less similar.<br>Remained 2 topics not deep discussed:<br>Auto=
matic parallel
 evaluation. This optimization is even harder in general, and it has to rel=
y on=20
as-if rules unconditionally in current C++ since no abstract machine=20
semantics provides such support. But it would likely gain much more than pl=
ain=20
arguments reordering.<br>Confusion for users using different languages. Thi=
s is especially significant for users switching between C and C++ daily, th=
ough I personally don&#39;t care too much.<br><br></div>

<p></p>

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

------=_Part_3910_1891981396.1457927220747--
------=_Part_3909_720233086.1457927220747--

.

--089e0158acb60cf49b052dfc99a8
Content-Type: text/plain; charset=UTF-8

On 13 Mar 2016 19:59, "Ross Smith" <ross.smith@otoy.com> wrote:
>
> On 2016-03-12 05:22, Hyman Rosen wrote:
>>
>>
>> Even very experienced C++ programmers do not notice problems with
>> undefined behavior due to order of evaluation, for two reasons.  First,
>> they do not remember that order of evaluation is an issue, since most of
>> the time it is not, and they do not know or remember the rules governing
>> it.  Second, the code communicates its intent so strongly that it is
>> psychologically difficult to accept that it does not do exactly what it
>> appears to.  Recall how novel it was to accept that f(new T, new T)
>> could leak memory even when the parameters were smart pointers.
>>   (Another nail in the coffin for unspecified order, papered over with
>> more accusations of bad code - "don't use new directly".)
>>
>> This means that the notion that such code will be weeded out by review
>> is fatally flawed; neither the authors nor the reviewers will see the
>> problem.  At best, with multiple increments, reviewers may feel some
>> suspicion because they may recall some folklore that such code is bad.
>> When the code involves multiple function calls and unspecified rather
>> than undefined behavior, I doubt that many reviewers will ever notice.
>
>
> If anyone is interested in an actual real-world example...
>
> Recently I wrote this bit of code:
>
>     if (listen(fd, 10) == -1)
>         throw system_error(errno, generic_category(), "listen(" +
to_string(fd) + ")");
>
> This isn't a contrived example, it's actual code that almost made it into
production, written by an experienced C++ programmer (I've been writing C++
for a living for more than 20 years). It wasn't until I started seeing some
funny-looking exceptions in testing that I realized what I'd done wrong. If
I hadn't been primed by following this thread I might still be scratching
my head :)
>
> When this debate first showed up on this list I would have said I was
mildly on the "leave it undefined" side, but now I'm convinced that the
"define the order already and be done with it" side is right.

But the only reason that code "works" with an ltr evaluation order is that
the parameter initialized by the impure variable errno happens to be the
leftmost parameter; if it were in any other position you would still have
to copy its value into a local variable; and indeed you still should, for
clarity.

--
You received this message because you are 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/CAJnLdOYiSToA8N6%2B8rrNfxK8x2iaWhNhYbfOYg8QTUHFv%3DLujA%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 13 Mar 2016 19:59, &quot;Ross Smith&quot; &lt;<a href=3D"mailto:ross.smi=
th@otoy.com">ross.smith@otoy.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 2016-03-12 05:22, Hyman Rosen wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Even very experienced C++ programmers do not notice problems with<=
br>
&gt;&gt; undefined behavior due to order of evaluation, for two reasons.=C2=
=A0 First,<br>
&gt;&gt; they do not remember that order of evaluation is an issue, since m=
ost of<br>
&gt;&gt; the time it is not, and they do not know or remember the rules gov=
erning<br>
&gt;&gt; it.=C2=A0 Second, the code communicates its intent so strongly tha=
t it is<br>
&gt;&gt; psychologically difficult to accept that it does not do exactly wh=
at it<br>
&gt;&gt; appears to.=C2=A0 Recall how novel it was to accept that f(new T, =
new T)<br>
&gt;&gt; could leak memory even when the parameters were smart pointers.<br=
>
&gt;&gt; =C2=A0 (Another nail in the coffin for unspecified order, papered =
over with<br>
&gt;&gt; more accusations of bad code - &quot;don&#39;t use new directly&qu=
ot;.)<br>
&gt;&gt;<br>
&gt;&gt; This means that the notion that such code will be weeded out by re=
view<br>
&gt;&gt; is fatally flawed; neither the authors nor the reviewers will see =
the<br>
&gt;&gt; problem.=C2=A0 At best, with multiple increments, reviewers may fe=
el some<br>
&gt;&gt; suspicion because they may recall some folklore that such code is =
bad.<br>
&gt;&gt; When the code involves multiple function calls and unspecified rat=
her<br>
&gt;&gt; than undefined behavior, I doubt that many reviewers will ever not=
ice.<br>
&gt;<br>
&gt;<br>
&gt; If anyone is interested in an actual real-world example...<br>
&gt;<br>
&gt; Recently I wrote this bit of code:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 if (listen(fd, 10) =3D=3D -1)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw system_error(errno, generic_category=
(), &quot;listen(&quot; + to_string(fd) + &quot;)&quot;);<br>
&gt;<br>
&gt; This isn&#39;t a contrived example, it&#39;s actual code that almost m=
ade it into production, written by an experienced C++ programmer (I&#39;ve =
been writing C++ for a living for more than 20 years). It wasn&#39;t until =
I started seeing some funny-looking exceptions in testing that I realized w=
hat I&#39;d done wrong. If I hadn&#39;t been primed by following this threa=
d I might still be scratching my head :)<br>
&gt;<br>
&gt; When this debate first showed up on this list I would have said I was =
mildly on the &quot;leave it undefined&quot; side, but now I&#39;m convince=
d that the &quot;define the order already and be done with it&quot; side is=
 right.</p>
<p dir=3D"ltr">But the only reason that code &quot;works&quot; with an ltr =
evaluation order is that the parameter initialized by the impure variable e=
rrno happens to be the leftmost parameter; if it were in any other position=
 you would still have to copy its value into a local variable; and indeed y=
ou still should, for clarity.</p>

<p></p>

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

--089e0158acb60cf49b052dfc99a8--

.

------=_Part_14_214824767.1457940971424
Content-Type: multipart/alternative;
 boundary="----=_Part_15_1221783652.1457940971425"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=882:43:28=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
> On 13 Mar 2016 19:59, "Ross Smith" <ross....@otoy.com <javascript:>>=20
> wrote:
> >
> > On 2016-03-12 05:22, Hyman Rosen wrote:
> >>
> >>
> >> Even very experienced C++ programmers do not notice problems with
> >> undefined behavior due to order of evaluation, for two reasons.  First=
,
> >> they do not remember that order of evaluation is an issue, since most =
of
> >> the time it is not, and they do not know or remember the rules governi=
ng
> >> it.  Second, the code communicates its intent so strongly that it is
> >> psychologically difficult to accept that it does not do exactly what i=
t
> >> appears to.  Recall how novel it was to accept that f(new T, new T)
> >> could leak memory even when the parameters were smart pointers.
> >>   (Another nail in the coffin for unspecified order, papered over with
> >> more accusations of bad code - "don't use new directly".)
> >>
> >> This means that the notion that such code will be weeded out by review
> >> is fatally flawed; neither the authors nor the reviewers will see the
> >> problem.  At best, with multiple increments, reviewers may feel some
> >> suspicion because they may recall some folklore that such code is bad.
> >> When the code involves multiple function calls and unspecified rather
> >> than undefined behavior, I doubt that many reviewers will ever notice.
> >
> >
> > If anyone is interested in an actual real-world example...
> >
> > Recently I wrote this bit of code:
> >
> >     if (listen(fd, 10) =3D=3D -1)
> >         throw system_error(errno, generic_category(), "listen(" +=20
> to_string(fd) + ")");
> >
> > This isn't a contrived example, it's actual code that almost made it=20
> into production, written by an experienced C++ programmer (I've been=20
> writing C++ for a living for more than 20 years). It wasn't until I start=
ed=20
> seeing some funny-looking exceptions in testing that I realized what I'd=
=20
> done wrong. If I hadn't been primed by following this thread I might stil=
l=20
> be scratching my head :)
> >
> > When this debate first showed up on this list I would have said I was=
=20
> mildly on the "leave it undefined" side, but now I'm convinced that the=
=20
> "define the order already and be done with it" side is right.
>
> But the only reason that code "works" with an ltr evaluation order is tha=
t=20
> the parameter initialized by the impure variable errno happens to be the=
=20
> leftmost parameter; if it were in any other position you would still have=
=20
> to copy its value into a local variable; and indeed you still should, for=
=20
> clarity.
>

And things will be nastier for Windows' ::GetLastError since you can't even=
=20
assume (via specification) which part of the standard library=20
implementation will modify the underlying value. Specifying evaluation=20
order will not help. Static/thread local error codes are always tricky in=
=20
such case. So just avoid such style.


--=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/90d10e4a-8538-49c9-8c28-ba8aaef54724%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=882:43:28=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 13 Mar 2016 19:59, &quot;Ross Smith&quot; &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"WfivL-IHCAAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this=
..href=3D&#39;javascript:&#39;;return true;">ross....@otoy.com</a>&gt; wrote=
:<br>
&gt;<br>
&gt; On 2016-03-12 05:22, Hyman Rosen wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Even very experienced C++ programmers do not notice problems with<=
br>
&gt;&gt; undefined behavior due to order of evaluation, for two reasons.=C2=
=A0 First,<br>
&gt;&gt; they do not remember that order of evaluation is an issue, since m=
ost of<br>
&gt;&gt; the time it is not, and they do not know or remember the rules gov=
erning<br>
&gt;&gt; it.=C2=A0 Second, the code communicates its intent so strongly tha=
t it is<br>
&gt;&gt; psychologically difficult to accept that it does not do exactly wh=
at it<br>
&gt;&gt; appears to.=C2=A0 Recall how novel it was to accept that f(new T, =
new T)<br>
&gt;&gt; could leak memory even when the parameters were smart pointers.<br=
>
&gt;&gt; =C2=A0 (Another nail in the coffin for unspecified order, papered =
over with<br>
&gt;&gt; more accusations of bad code - &quot;don&#39;t use new directly&qu=
ot;.)<br>
&gt;&gt;<br>
&gt;&gt; This means that the notion that such code will be weeded out by re=
view<br>
&gt;&gt; is fatally flawed; neither the authors nor the reviewers will see =
the<br>
&gt;&gt; problem.=C2=A0 At best, with multiple increments, reviewers may fe=
el some<br>
&gt;&gt; suspicion because they may recall some folklore that such code is =
bad.<br>
&gt;&gt; When the code involves multiple function calls and unspecified rat=
her<br>
&gt;&gt; than undefined behavior, I doubt that many reviewers will ever not=
ice.<br>
&gt;<br>
&gt;<br>
&gt; If anyone is interested in an actual real-world example...<br>
&gt;<br>
&gt; Recently I wrote this bit of code:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 if (listen(fd, 10) =3D=3D -1)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw system_error(errno, generic_category=
(), &quot;listen(&quot; + to_string(fd) + &quot;)&quot;);<br>
&gt;<br>
&gt; This isn&#39;t a contrived example, it&#39;s actual code that almost m=
ade it into production, written by an experienced C++ programmer (I&#39;ve =
been writing C++ for a living for more than 20 years). It wasn&#39;t until =
I started seeing some funny-looking exceptions in testing that I realized w=
hat I&#39;d done wrong. If I hadn&#39;t been primed by following this threa=
d I might still be scratching my head :)<br>
&gt;<br>
&gt; When this debate first showed up on this list I would have said I was =
mildly on the &quot;leave it undefined&quot; side, but now I&#39;m convince=
d that the &quot;define the order already and be done with it&quot; side is=
 right.</p>
<p dir=3D"ltr">But the only reason that code &quot;works&quot; with an ltr =
evaluation order is that the parameter initialized by the impure variable e=
rrno happens to be the leftmost parameter; if it were in any other position=
 you would still have to copy its value into a local variable; and indeed y=
ou still should, for clarity.</p></blockquote><div><br>And things will be n=
astier for Windows&#39; ::GetLastError since you can&#39;t even assume (via=
 specification) which part of the standard library implementation will modi=
fy the underlying value. Specifying evaluation order will not help. Static/=
thread local error codes are always tricky in such case. So just avoid such=
 style.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/90d10e4a-8538-49c9-8c28-ba8aaef54724%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90d10e4a-8538-49c9-8c28-ba8aaef54724=
%40isocpp.org</a>.<br />

------=_Part_15_1221783652.1457940971425--
------=_Part_14_214824767.1457940971424--

.

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

2016-03-13 21:50 GMT+03:30 FrankHB1989 <frankhb1989@gmail.com>:

>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8B=E5=8D=883:55:56=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>>
>>
>> 2016-03-12 6:51 GMT+03:30 Greg Marr <greg...@gmail.com>:
>>
>>> For those that haven't seen this yet:
>>>
>>>
>>> http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-mee=
ting/
>>>
>>> Evolution also approved the following features that were not voted in a=
t
>>> this meeting, but are currently on track for possible approval for C++1=
7 at
>>> our next meeting in June for inclusion in the C++17 international comme=
nt
>>> ballot
>>>
>>> Defining the order of expression evaluation to reduce portability and
>>> usability bugs.
>>>
>>
>> =E2=80=8BInteresting read!!!
>> By the way, has anybody mentioned that the most natural order might be
>> that of combining operators with operands(ie rules of associativity and
>> precedence)?=E2=80=8B
>>
>> Most natural? Either forget all those operators and operands, pretending
> you are writing natural language, and let the compiler to do NLP; or use
> some other writing system to make the need of associativity and
> precedence away, specifically, without infix expressions, to get the
> simplest set of order rules.
>

=E2=80=8BIt looks like early creators=E2=80=8B of C++ have made them easy t=
o remember. I
don't even think of binding order when writing compound operator
expressions. Because that's the first thing a C++ programmer learns and
practice curves it in memory.


> All not feasible in C++. Relying on "rules of associativity and
> precedence" is far from "natural" for users.
>

=E2=80=8BNothing is natural for =E2=80=8Bprogrammers; they have a tool (C++=
) and they need
to make with it. But it is natural to the language. Correct binding of
operators and operators matters to any programmer; misuse of operators
leads to bugs and errors in simplest programs (where ordering does not
affect the outcome). So every programmer needs to care about precedence and
associativity:

*(x++);
*x++;
(*x)++;

can you tell the difference between the above lines without referring to
binding order? This has been the style since day  1 in C and lots code has
been written around it. Any ordering that deviates the binding order,
eventually breaks existing practical well-defined code.

Separating the rules of ordering from binding adds another set of rules and
leads to more confusion. Such ordering also facilitates better chaining
through implicit parallelism; Consider the comma operator as a
left-associative operator:

(a,b,c);

by the time 'b' is evaluated the result of l-most comma which is 'a' might
actually be ready and by time 'c' is evaluated, the overall result of the
operation might long have been evaluated. It happens to be that the
proposed exceptions to LTR in existing drafts, are all right-associative
operators. Regarding precedence is important in expressions with
heterogeneous chaining(in contrast to the homogeneous chaining in the above
sample); eg in the famous cout example:

cout << (x=3D3) << x-- << x-- << x;

Since post-dec operator is more precedent than l-shift, the expected output
will be 3321. Other evaluation orders wouldn't lead to pleasant outputs.

Few people will remember all those rules correctly.
>

=E2=80=8BNot quite that few, but fewer will remember both set of rules
simultaneously(one for binding the other for evaluation)!!!

Also note "associativity and precedence" needs some additional wording in
> the standard.
>

=E2=80=8BSo be it. That should not be an obstacle =E2=80=8Bagainst conforma=
nt binding and
evaluation orders.

--=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/CALDL7dG450LHPNbOj2B7OoLcSFVjYvf3Pz7FyEQ4%3DASZj=
eWHZA%40mail.gmail.com.

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

<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:arial na=
rrow,sans-serif;font-size:large"><br></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote"><div dir=3D"ltr">2016-03-13 21:50 GMT+03:30 Frank=
HB1989 <span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com" targe=
t=3D"_blank">frankhb1989@gmail.com</a>&gt;</span>:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-r=
ight:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><b=
r><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=
=AD UTC+8=E4=B8=8B=E5=8D=883:55:56=EF=BC=8CFarid Mehrabi=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"rtl"><div styl=
e=3D"font-family:arial narrow,sans-serif;font-size:large"><br></div><div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr">2016-03-12 6:51 GMT+03:30 Gre=
g Marr <span dir=3D"ltr">&lt;<a rel=3D"nofollow">greg...@gmail.com</a>&gt;<=
/span>:</div><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">For those that=
 haven&#39;t seen this yet:<br><br><a href=3D"http://herbsutter.com/2016/03=
/11/trip-report-winter-iso-c-standards-meeting/" rel=3D"nofollow" target=3D=
"_blank">http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standard=
s-meeting/</a><br><br>Evolution also approved the following features that w=
ere not voted in at this meeting, but are currently on track for possible a=
pproval for C++17 at our next meeting in June for inclusion in the C++17 in=
ternational comment ballot<div><br>Defining the order of expression evaluat=
ion to reduce portability and usability bugs.</div></div></blockquote></div=
><div dir=3D"ltr"><br></div><div dir=3D"ltr"><div style=3D"font-family:&#39=
;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8BInteresting read!!!=
=C2=A0</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;fon=
t-size:large">By the way, has anybody mentioned that the most natural order=
 might be that of combining operators with operands(ie rules of associativi=
ty and precedence)?=E2=80=8B</div><div style=3D"font-family:&#39;arial narr=
ow&#39;,sans-serif;font-size:large"><br></div></div></div></div></blockquot=
e><div>Most natural? Either forget all those operators and operands, preten=
ding you are writing natural language, and let the compiler to do NLP; or u=
se some other writing system to make the need of <span>associativity </span=
>and precedence away, specifically, without infix expressions, to get the s=
implest set of order rules. </div></div></blockquote><div style=3D"directio=
n:ltr"><br></div><div style=3D"direction:ltr"><div class=3D"gmail_default" =
style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=
=80=8BIt looks like early creators=E2=80=8B of C++ have made them easy to r=
emember. I don&#39;t even think of binding order when writing compound oper=
ator expressions. Because that&#39;s the first thing a C++ programmer learn=
s and practice curves it in memory.</div></div><div style=3D"direction:ltr"=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 .8ex;borde=
r-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;padding-=
right:1ex"><div dir=3D"ltr"><div>All not feasible in C++. Relying on &quot;=
rules of <span>associativity and precedence&quot; is far from &quot;natural=
&quot; for users.</span></div></div></blockquote><div style=3D"direction:lt=
r">=C2=A0</div><div style=3D"direction:ltr"><div class=3D"gmail_default" st=
yle=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=
=80=8BNothing is natural for =E2=80=8Bprogrammers; they have a tool (C++) a=
nd they need to make with it. But it is natural to the language. Correct bi=
nding of operators and operators matters to any programmer; misuse of opera=
tors leads to bugs and errors in simplest programs (where ordering does not=
 affect the outcome). So every programmer needs to care about precedence an=
d associativity:</div><div class=3D"gmail_default" style=3D"font-family:&#3=
9;arial narrow&#39;,sans-serif;font-size:large"><br></div><div class=3D"gma=
il_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-siz=
e:large">*(x++);</div><div class=3D"gmail_default" style=3D"font-family:&#3=
9;arial narrow&#39;,sans-serif;font-size:large">*x++;</div><div class=3D"gm=
ail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-si=
ze:large">(*x)++;</div><div class=3D"gmail_default" style=3D"font-family:&#=
39;arial narrow&#39;,sans-serif;font-size:large"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-si=
ze:large">can you tell the difference between the above lines without refer=
ring to binding order? This has been the style since day =C2=A01 in C and l=
ots code has been written around it. Any ordering that deviates the binding=
 order, eventually breaks existing practical well-defined code.</div><div c=
lass=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-ser=
if;font-size:large"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:&#39;arial narrow&#39;,sans-serif;font-size:large">Separating the rule=
s of ordering from binding adds another set of rules and leads to more conf=
usion. Such ordering also facilitates better chaining through implicit para=
llelism; Consider the comma operator as a left-associative operator:</div><=
div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,san=
s-serif;font-size:large"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:&#39;arial narrow&#39;,sans-serif;font-size:large">(a,b,c);</div>=
<div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sa=
ns-serif;font-size:large"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;arial narrow&#39;,sans-serif;font-size:large">by the time &=
#39;b&#39; is evaluated the result of l-most comma which is &#39;a&#39; mig=
ht actually be ready and by time &#39;c&#39; is evaluated, the overall resu=
lt of the operation might long have been evaluated. It happens to be that t=
he proposed exceptions to LTR in existing drafts, are all right-associative=
 operators. Regarding precedence is important in expressions with heterogen=
eous chaining(in contrast to the homogeneous chaining in the above sample);=
 eg in the famous cout example:</div><div class=3D"gmail_default" style=3D"=
font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans=
-serif;font-size:large">cout &lt;&lt; (x=3D3) &lt;&lt; x-- &lt;&lt; x-- &lt=
;&lt; x;</div><div class=3D"gmail_default" style=3D"font-family:&#39;arial =
narrow&#39;,sans-serif;font-size:large"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"=
>Since post-dec operator is more precedent than l-shift, the expected outpu=
t will be 3321. Other evaluation orders wouldn&#39;t lead to pleasant outpu=
ts.</div></div><div style=3D"direction:ltr"><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right=
:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div><=
span> Few people will remember all those rules correctly.</span></div></div=
></blockquote><div style=3D"direction:ltr">=C2=A0</div><div style=3D"direct=
ion:ltr"><div class=3D"gmail_default" style=3D"font-family:&#39;arial narro=
w&#39;,sans-serif;font-size:large">=E2=80=8BNot quite that few, but fewer w=
ill remember both set of rules simultaneously(one for binding the other for=
 evaluation)!!!</div></div><div style=3D"direction:ltr"><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;=
border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D=
"ltr"><div><span> Also note &quot;associativity and precedence&quot; needs =
some additional wording in the standard.</span></div></div></blockquote><di=
v style=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><div class=
=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large">=E2=80=8BSo be it. That should not be an obstacle =E2=80=8B=
against conformant binding and evaluation orders.</div><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dG450LHPNbOj2B7OoLcSFVjYvf3Pz7F=
yEQ4%3DASZjeWHZA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dG450LHPN=
bOj2B7OoLcSFVjYvf3Pz7FyEQ4%3DASZjeWHZA%40mail.gmail.com</a>.<br />

--001a113a7eaea09137052e0052db--

.

------=_Part_4777_1329521469.1457960072294
Content-Type: multipart/alternative;
 boundary="----=_Part_4778_1263522180.1457960072295"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=887:10:07=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> 2016-03-13 21:50 GMT+03:30 FrankHB1989 <frank...@gmail.com <javascript:>>=
:
>
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8B=E5=8D=883:55:56=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> 2016-03-12 6:51 GMT+03:30 Greg Marr <greg...@gmail.com>:
>
> For those that haven't seen this yet:
>
>
> http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeti=
ng/
>
> Evolution also approved the following features that were not voted in at=
=20
> this meeting, but are currently on track for possible approval for C++17 =
at=20
> our next meeting in June for inclusion in the C++17 international comment=
=20
> ballot
>
> Defining the order of expression evaluation to reduce portability and=20
> usability bugs.
>
>
> =E2=80=8BInteresting read!!!=20
> By the way, has anybody mentioned that the most natural order might be=20
> that of combining operators with operands(ie rules of associativity and=
=20
> precedence)?=E2=80=8B
>
> Most natural? Either forget all those operators and operands, pretending=
=20
> you are writing natural language, and let the compiler to do NLP; or use=
=20
> some other writing system to make the need of associativity and=20
> precedence away, specifically, without infix expressions, to get the=20
> simplest set of order rules.=20
>
>
> =E2=80=8BIt looks like early creators=E2=80=8B of C++ have made them easy=
 to remember. I=20
> don't even think of binding order when writing compound operator=20
> expressions. Because that's the first thing a C++ programmer learns and=
=20
> practice curves it in memory.
>
Not so simple. Most operators are same to C. However, what about .* or ->*?=
=20
Do they meet "natural" you said? I have seen many people surprised by=20
them. =20

> =20
>
> All not feasible in C++. Relying on "rules of associativity and=20
> precedence" is far from "natural" for users.
>
> =20
> =E2=80=8BNothing is natural for =E2=80=8Bprogrammers; they have a tool (C=
++) and they need=20
> to make with it. But it is natural to the language. Correct binding of=20
> operators and operators matters to any programmer; misuse of operators=20
> leads to bugs and errors in simplest programs (where ordering does not=20
> affect the outcome). So every programmer needs to care about precedence a=
nd=20
> associativity:
>
> Are you serious? There is nothing named "binding order" of operators in=
=20
C++. The language itself does not mix the syntax and semantics rules at all=
=20
in these cases. Grouping of operators and operands are specified by the=20
syntax. Precedence and associativity are pure syntactic properties, and how=
=20
to evaluate them is not related with these rules. They should be cared=20
about because different forms of syntax have may different meaning, which=
=20
cannot be determined by syntax rules solely. Correct knowledge of=20
precedence and associativity is *never enough* to make an expression behave=
=20
as you expected.

*(x++);
> *x++;
> (*x)++;
>
> can you tell the difference between the above lines without referring to=
=20
> binding order? This has been the style since day  1 in C and lots code ha=
s=20
> been written around it. Any ordering that deviates the binding order,=20
> eventually breaks existing practical well-defined code.
>
> How can the code still be "well-defined" if it is violating the language=
=20
rules for decades?
=20

> Separating the rules of ordering from binding adds another set of rules=
=20
> and leads to more confusion.
>
Maybe. But ignorance of the difference do confused users as well. They=20
eventually have to know the different sets of rules are different in=20
nature. Mixing them is always artificial.
=20

> Such ordering also facilitates better chaining through implicit=20
> parallelism; Consider the comma operator as a left-associative operator:
>
> (a,b,c);
>
> by the time 'b' is evaluated the result of l-most comma which is 'a' migh=
t=20
> actually be ready and by time 'c' is evaluated, the overall result of the=
=20
> operation might long h
> ...

If you need the order here... why not just "a; b; c;"? It is more explicit=
=20
and reliable. Your expectation here is fragile, since C++ allows=20
overloading of "operator,".
=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/43535972-6b5b-4c38-8dd8-21685c33d03b%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=887:10:07=EF=BC=8CFarid Mehrabi=
=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"rtl"><div style=3D"font-family:arial narrow,sans-serif;font-size:l=
arge"><br></div><div><br><div><div dir=3D"ltr">2016-03-13 21:50 GMT+03:30 F=
rankHB1989 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"d972bm8WCAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">frank...@gmail.com</a>&gt;</span>:</div><blockq=
uote style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #cc=
c solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><br><br>=E5=9C=
=A8 2016=E5=B9=B43=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=
=B8=8B=E5=8D=883:55:56=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=9A<blo=
ckquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"rtl"><div style=3D"font-family:arial narrow,sans-=
serif;font-size:large"><br></div><div><br><div><div dir=3D"ltr">2016-03-12 =
6:51 GMT+03:30 Greg Marr <span dir=3D"ltr">&lt;<a rel=3D"nofollow">greg...@=
gmail.com</a>&gt;</span>:</div><blockquote style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">For those that hav=
en&#39;t seen this yet:<br><br><a href=3D"http://herbsutter.com/2016/03/11/=
trip-report-winter-iso-c-standards-meeting/" rel=3D"nofollow" target=3D"_bl=
ank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%=
2F%2Fherbsutter.com%2F2016%2F03%2F11%2Ftrip-report-winter-iso-c-standards-m=
eeting%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFZ3B3a9QEjcfgwYx8CEw1gJTtchA&#=
39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fherbsutter.com%2F2016%2F03%2F11%2Ftrip-report-winter-iso-c-st=
andards-meeting%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFZ3B3a9QEjcfgwYx8CEw1=
gJTtchA&#39;;return true;">http://herbsutter.com/2016/03/<wbr>11/trip-repor=
t-winter-iso-c-<wbr>standards-meeting/</a><br><br>Evolution also approved t=
he following features that were not voted in at this meeting, but are curre=
ntly on track for possible approval for C++17 at our next meeting in June f=
or inclusion in the C++17 international comment ballot<div><br>Defining the=
 order of expression evaluation to reduce portability and usability bugs.</=
div></div></blockquote></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><d=
iv style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=
=E2=80=8BInteresting read!!!=C2=A0</div><div style=3D"font-family:&#39;aria=
l narrow&#39;,sans-serif;font-size:large">By the way, has anybody mentioned=
 that the most natural order might be that of combining operators with oper=
ands(ie rules of associativity and precedence)?=E2=80=8B</div><div style=3D=
"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div><=
/div></div></div></blockquote><div>Most natural? Either forget all those op=
erators and operands, pretending you are writing natural language, and let =
the compiler to do NLP; or use some other writing system to make the need o=
f <span>associativity </span>and precedence away, specifically, without inf=
ix expressions, to get the simplest set of order rules. </div></div></block=
quote><div style=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><=
div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"=
>=E2=80=8BIt looks like early creators=E2=80=8B of C++ have made them easy =
to remember. I don&#39;t even think of binding order when writing compound =
operator expressions. Because that&#39;s the first thing a C++ programmer l=
earns and practice curves it in memory.</div></div></div></div></div></bloc=
kquote><div>Not so simple. Most operators are same to C. However, what abou=
t .* or -&gt;*? Do they meet &quot;natural&quot; you said? I have seen many=
 people surprised by them.=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"rtl"><div><div><div style=3D"direction:ltr">=C2=A0=
</div><blockquote style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-=
right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><=
div>All not feasible in C++. Relying on &quot;rules of <span>associativity =
and precedence&quot; is far from &quot;natural&quot; for users.</span></div=
></div></blockquote><div style=3D"direction:ltr">=C2=A0</div><div style=3D"=
direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;=
font-size:large">=E2=80=8BNothing is natural for =E2=80=8Bprogrammers; they=
 have a tool (C++) and they need to make with it. But it is natural to the =
language. Correct binding of operators and operators matters to any program=
mer; misuse of operators leads to bugs and errors in simplest programs (whe=
re ordering does not affect the outcome). So every programmer needs to care=
 about precedence and associativity:</div><div style=3D"font-family:&#39;ar=
ial narrow&#39;,sans-serif;font-size:large"><br></div></div></div></div></d=
iv></blockquote><div>Are you serious? There is nothing named &quot;binding =
order&quot; of operators in C++. The language itself does not mix the synta=
x and semantics rules at all in these cases. Grouping of operators and oper=
ands are specified by the syntax. Precedence and associativity are pure syn=
tactic properties, and how to evaluate them is not related with these rules=
.. They should be cared about because different forms of syntax have may dif=
ferent meaning, which cannot be determined by syntax rules solely. Correct =
knowledge of precedence and associativity is <i>never enough</i> to make an=
 expression behave as you expected.<br><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"rtl"><div><div><div style=3D"direction:ltr">=
<div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large=
"></div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-si=
ze:large">*(x++);</div><div style=3D"font-family:&#39;arial narrow&#39;,san=
s-serif;font-size:large">*x++;</div><div style=3D"font-family:&#39;arial na=
rrow&#39;,sans-serif;font-size:large">(*x)++;</div><div style=3D"font-famil=
y:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">can you =
tell the difference between the above lines without referring to binding or=
der? This has been the style since day =C2=A01 in C and lots code has been =
written around it. Any ordering that deviates the binding order, eventually=
 breaks existing practical well-defined code.</div><div style=3D"font-famil=
y:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div></div></div>=
</div></div></blockquote><div>How can the code still be &quot;well-defined&=
quot; if it is violating the language rules for decades?<br>=C2=A0<br></div=
><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"rtl"><div><div><d=
iv style=3D"direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39;=
,sans-serif;font-size:large"></div><div style=3D"font-family:&#39;arial nar=
row&#39;,sans-serif;font-size:large">Separating the rules of ordering from =
binding adds another set of rules and leads to more confusion.</div></div><=
/div></div></div></blockquote><div>Maybe. But ignorance of the difference d=
o confused users as well. They eventually have to know the different sets o=
f rules are different in nature. Mixing them is always artificial.<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"rtl"><div=
><div><div style=3D"direction:ltr"><div style=3D"font-family:&#39;arial nar=
row&#39;,sans-serif;font-size:large">Such ordering also facilitates better =
chaining through implicit parallelism; Consider the comma operator as a lef=
t-associative operator:</div><div style=3D"font-family:&#39;arial narrow&#3=
9;,sans-serif;font-size:large"><br></div><div style=3D"font-family:&#39;ari=
al narrow&#39;,sans-serif;font-size:large">(a,b,c);</div><div style=3D"font=
-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div><div s=
tyle=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">by t=
he time &#39;b&#39; is evaluated the result of l-most comma which is &#39;a=
&#39; might actually be ready and by time &#39;c&#39; is evaluated, the ove=
rall result of the operation might long h</div></div></div></div></div>...<=
/blockquote><div>If you need the order here... why not just &quot;a; b; c;&=
quot;? It is more explicit and reliable. Your expectation here is fragile, =
since C++ allows overloading of &quot;operator,&quot;.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/43535972-6b5b-4c38-8dd8-21685c33d03b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43535972-6b5b-4c38-8dd8-21685c33d03b=
%40isocpp.org</a>.<br />

------=_Part_4778_1263522180.1457960072295--
------=_Part_4777_1329521469.1457960072294--

.

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

On Mon, Mar 14, 2016 at 2:43 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> But the only reason that code "works" with an ltr evaluation order is that
> the parameter initialized by the impure variable errno happens to be the
> leftmost parameter; if it were in any other position you would still have
> to copy its value into a local variable; and indeed you still should, for
> clarity.
>

The point is not that the code works with left-to-right order of
evaluation.  The point is that if the compiler had chosen left-to-right
order of evaluation there would have been a latent error in the code that
would only appear with a change of the build environment.  With a specified
order of evaluation, if the code works then it works, and if it doesn't the
error shows up right 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/CAHSYqdawvNUJyan0TWeTJgiA_4x2rBwWXQQ%2B3SW8HwrA3YUr4w%40mail.gmail.com.

--001a1148d8f8232f1f052e03cac9
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, Mar 14, 2016 at 2:43 AM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</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">But the only reason that code &quot;works&quot; with =
an ltr evaluation order is that the parameter initialized by the impure var=
iable errno happens to be the leftmost parameter; if it were in any other p=
osition you would still have to copy its value into a local variable; and i=
ndeed you still should, for clarity.</p></blockquote><div><br>The point is =
not that the code works with left-to-right order of evaluation.=C2=A0 The p=
oint is that if the compiler had chosen left-to-right order of evaluation t=
here would have been a latent error in the code that would only appear with=
 a change of the build environment.=C2=A0 With a specified order of evaluat=
ion, if the code works then it works, and if it doesn&#39;t the error shows=
 up right 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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdawvNUJyan0TWeTJgiA_4x2rBwWXQQ%=
2B3SW8HwrA3YUr4w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdawvNUJya=
n0TWeTJgiA_4x2rBwWXQQ%2B3SW8HwrA3YUr4w%40mail.gmail.com</a>.<br />

--001a1148d8f8232f1f052e03cac9--

.

--047d7bdca440995f91052e071453
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 14, 2016 at 3:17 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Mon, Mar 14, 2016 at 2:43 AM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> But the only reason that code "works" with an ltr evaluation order is
>> that the parameter initialized by the impure variable errno happens to be
>> the leftmost parameter; if it were in any other position you would still
>> have to copy its value into a local variable; and indeed you still should,
>> for clarity.
>>
>
> The point is not that the code works with left-to-right order of
> evaluation.  The point is that if the compiler had chosen left-to-right
> order of evaluation there would have been a latent error in the code that
> would only appear with a change of the build environment.  With a specified
> order of evaluation, if the code works then it works, and if it doesn't the
> error shows up right away.
>

The code "works if it works" only until it is modified, and code relying on
(in this case) the ordering of accesses to a global variable is so fragile
that will break sooner or later under ordinary maintenance, and usually
sooner than any change in build environment.

--
You received this message because you are 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/CAJnLdObdO%3DdO68Kcq4pczMi-yL4K%2BP41mbJ54Eqi0zbNRf4Xdw%40mail.gmail.com.

--047d7bdca440995f91052e071453
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, Mar 14, 2016 at 3:17 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.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"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Mar 14, 2016 at 2:43 =
AM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>&gt;</span> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span>
</span><p dir=3D"ltr">But the only reason that code &quot;works&quot; with =
an ltr evaluation order is that the parameter initialized by the impure var=
iable errno happens to be the leftmost parameter; if it were in any other p=
osition you would still have to copy its value into a local variable; and i=
ndeed you still should, for clarity.</p></blockquote><div><br>The point is =
not that the code works with left-to-right order of evaluation.=C2=A0 The p=
oint is that if the compiler had chosen left-to-right order of evaluation t=
here would have been a latent error in the code that would only appear with=
 a change of the build environment.=C2=A0 With a specified order of evaluat=
ion, if the code works then it works, and if it doesn&#39;t the error shows=
 up right away.</div></div></div></div></blockquote><div><br></div><div>The=
 code &quot;works if it works&quot; only until it is modified, and code rel=
ying on (in this case) the ordering of accesses to a global variable is so =
fragile that will break sooner or later under ordinary maintenance, and usu=
ally sooner than any change in build environment.</div></div><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObdO%3DdO68Kcq4pczMi-yL4K%2BP41=
mbJ54Eqi0zbNRf4Xdw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObdO%3D=
dO68Kcq4pczMi-yL4K%2BP41mbJ54Eqi0zbNRf4Xdw%40mail.gmail.com</a>.<br />

--047d7bdca440995f91052e071453--

.

On 2016-03-14 20:36, FrankHB1989 wrote:
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 U=
TC+8=E4=B8=8B=E5=8D=882:43:28=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>     On 13 Mar 2016 19:59, "Ross Smith" <ross....@otoy.com <javascript:>>
>     wrote:
>      >
>      > On 2016-03-12 05:22, Hyman Rosen wrote:
>      >>
>      >>
>      >> Even very experienced C++ programmers do not notice problems with
>      >> undefined behavior due to order of evaluation, for two reasons.
>     First,
>      >> they do not remember that order of evaluation is an issue, since
>     most of
>      >> the time it is not, and they do not know or remember the rules
>     governing
>      >> it.  Second, the code communicates its intent so strongly that it=
 is
>      >> psychologically difficult to accept that it does not do exactly
>     what it
>      >> appears to.  Recall how novel it was to accept that f(new T, new =
T)
>      >> could leak memory even when the parameters were smart pointers.
>      >>   (Another nail in the coffin for unspecified order, papered
>     over with
>      >> more accusations of bad code - "don't use new directly".)
>      >>
>      >> This means that the notion that such code will be weeded out by
>     review
>      >> is fatally flawed; neither the authors nor the reviewers will
>     see the
>      >> problem.  At best, with multiple increments, reviewers may feel s=
ome
>      >> suspicion because they may recall some folklore that such code
>     is bad.
>      >> When the code involves multiple function calls and unspecified
>     rather
>      >> than undefined behavior, I doubt that many reviewers will ever
>     notice.
>      >
>      >
>      > If anyone is interested in an actual real-world example...
>      >
>      > Recently I wrote this bit of code:
>      >
>      >     if (listen(fd, 10) =3D=3D -1)
>      >         throw system_error(errno, generic_category(), "listen(" +
>     to_string(fd) + ")");
>      >
>      > This isn't a contrived example, it's actual code that almost made
>     it into production, written by an experienced C++ programmer (I've
>     been writing C++ for a living for more than 20 years). It wasn't
>     until I started seeing some funny-looking exceptions in testing that
>     I realized what I'd done wrong. If I hadn't been primed by following
>     this thread I might still be scratching my head :)
>      >
>      > When this debate first showed up on this list I would have said I
>     was mildly on the "leave it undefined" side, but now I'm convinced
>     that the "define the order already and be done with it" side is right=
..
>
>     But the only reason that code "works" with an ltr evaluation order
>     is that the parameter initialized by the impure variable errno
>     happens to be the leftmost parameter; if it were in any other
>     position you would still have to copy its value into a local
>     variable; and indeed you still should, for clarity.
>
>
> And things will be nastier for Windows' ::GetLastError since you can't
> even assume (via specification) which part of the standard library
> implementation will modify the underlying value. Specifying evaluation
> order will not help. Static/thread local error codes are always tricky
> in such case. So just avoid such style.

No, GetLastError() (or WSAGetLastError(), which is what I actually call=20
in the Windows version of this code) is effectively the same as errno in=20
this context. Given guaranteed LTR evaluation, both errno and=20
[WSA]GetLastError() would be safe, since nothing else happens between=20
the call to listen() and querying the error code. The failures I saw=20
happened because the string manipulation in the third constructor=20
argument can modify errno if the compiler chooses to evaluate the=20
arguments to system_error's constructor from right to left; in a=20
hypothetical future C++ with mandatory LTR evaluation this wouldn't be a=20
problem.

Ross Smith

--=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/56E70FF5.8060105%40otoy.com.

.

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

On 14 Mar 2016 19:24, "Ross Smith" <ross.smith@otoy.com> wrote:
>
> On 2016-03-14 20:36, FrankHB1989 wrote:
>>
>>
>>
>> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 =
UTC+8=E4=B8=8B=E5=8D=882:43:28=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>>
>>     On 13 Mar 2016 19:59, "Ross Smith" <ross....@otoy.com <javascript:>>
>>
>>     wrote:
>>      >
>>      > On 2016-03-12 05:22, Hyman Rosen wrote:
>>      >>
>>      >>
>>      >> Even very experienced C++ programmers do not notice problems wit=
h
>>      >> undefined behavior due to order of evaluation, for two reasons.
>>     First,
>>      >> they do not remember that order of evaluation is an issue, since
>>     most of
>>      >> the time it is not, and they do not know or remember the rules
>>     governing
>>      >> it.  Second, the code communicates its intent so strongly that
it is
>>      >> psychologically difficult to accept that it does not do exactly
>>     what it
>>      >> appears to.  Recall how novel it was to accept that f(new T, new
T)
>>      >> could leak memory even when the parameters were smart pointers.
>>      >>   (Another nail in the coffin for unspecified order, papered
>>     over with
>>      >> more accusations of bad code - "don't use new directly".)
>>      >>
>>      >> This means that the notion that such code will be weeded out by
>>     review
>>      >> is fatally flawed; neither the authors nor the reviewers will
>>     see the
>>      >> problem.  At best, with multiple increments, reviewers may feel
some
>>      >> suspicion because they may recall some folklore that such code
>>     is bad.
>>      >> When the code involves multiple function calls and unspecified
>>     rather
>>      >> than undefined behavior, I doubt that many reviewers will ever
>>     notice.
>>      >
>>      >
>>      > If anyone is interested in an actual real-world example...
>>      >
>>      > Recently I wrote this bit of code:
>>      >
>>      >     if (listen(fd, 10) =3D=3D -1)
>>      >         throw system_error(errno, generic_category(), "listen(" +
>>     to_string(fd) + ")");
>>      >
>>      > This isn't a contrived example, it's actual code that almost made
>>     it into production, written by an experienced C++ programmer (I've
>>     been writing C++ for a living for more than 20 years). It wasn't
>>     until I started seeing some funny-looking exceptions in testing that
>>     I realized what I'd done wrong. If I hadn't been primed by following
>>     this thread I might still be scratching my head :)
>>      >
>>      > When this debate first showed up on this list I would have said I
>>     was mildly on the "leave it undefined" side, but now I'm convinced
>>     that the "define the order already and be done with it" side is
right.
>>
>>     But the only reason that code "works" with an ltr evaluation order
>>     is that the parameter initialized by the impure variable errno
>>     happens to be the leftmost parameter; if it were in any other
>>     position you would still have to copy its value into a local
>>     variable; and indeed you still should, for clarity.
>>
>>
>> And things will be nastier for Windows' ::GetLastError since you can't
>> even assume (via specification) which part of the standard library
>> implementation will modify the underlying value. Specifying evaluation
>> order will not help. Static/thread local error codes are always tricky
>> in such case. So just avoid such style.
>
>
> No, GetLastError() (or WSAGetLastError(), which is what I actually call
in the Windows version of this code) is effectively the same as errno in
this context. Given guaranteed LTR evaluation, both errno and
[WSA]GetLastError() would be safe, since nothing else happens between the
call to listen() and querying the error code. The failures I saw happened
because the string manipulation in the third constructor argument can
modify errno if the compiler chooses to evaluate the arguments to
system_error's constructor from right to left; in a hypothetical future C++
with mandatory LTR evaluation this wouldn't be a problem.
>

You still need to ensure that "nothing else happens between the call to
listen() and querying the error code" - which might be true for the code as
presented, but can you guarantee that the access to errno or call to
GetLastError will still be the first operand of the expression after a few
months' worth of commits?

The difference between Windows and POSIX is that the latter at least
specifies which standard library functions can set errno, but as that
includes memory allocation and even math functions it's a guarantee that
isn't worth much.

--=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/CAJnLdObwsmWOLAxgm48D9a8-UjF-rDxCBPDveyfxPqn9TJA=
gQQ%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 14 Mar 2016 19:24, &quot;Ross Smith&quot; &lt;<a href=3D"mailto:ross.smi=
th@otoy.com">ross.smith@otoy.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 2016-03-14 20:36, FrankHB1989 wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=80 UTC+8=E4=B8=8B=E5=8D=882:43:28=EF=BC=8CEdward Catmur=E5=86=99=E9=81=
=93=EF=BC=9A<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 On 13 Mar 2016 19:59, &quot;Ross Smith&quot; &lt;<a =
href=3D"mailto:ross....@otoy.com">ross....@otoy.com</a> &lt;javascript:&gt;=
&gt;<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 wrote:<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; On 2016-03-12 05:22, Hyman Rosen wrote:<b=
r>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; Even very experienced C++ programmers=
 do not notice problems with<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; undefined behavior due to order of ev=
aluation, for two reasons.<br>
&gt;&gt; =C2=A0 =C2=A0 First,<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; they do not remember that order of ev=
aluation is an issue, since<br>
&gt;&gt; =C2=A0 =C2=A0 most of<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; the time it is not, and they do not k=
now or remember the rules<br>
&gt;&gt; =C2=A0 =C2=A0 governing<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; it.=C2=A0 Second, the code communicat=
es its intent so strongly that it is<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; psychologically difficult to accept t=
hat it does not do exactly<br>
&gt;&gt; =C2=A0 =C2=A0 what it<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; appears to.=C2=A0 Recall how novel it=
 was to accept that f(new T, new T)<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; could leak memory even when the param=
eters were smart pointers.<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt;=C2=A0 =C2=A0(Another nail in the coff=
in for unspecified order, papered<br>
&gt;&gt; =C2=A0 =C2=A0 over with<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; more accusations of bad code - &quot;=
don&#39;t use new directly&quot;.)<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; This means that the notion that such =
code will be weeded out by<br>
&gt;&gt; =C2=A0 =C2=A0 review<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; is fatally flawed; neither the author=
s nor the reviewers will<br>
&gt;&gt; =C2=A0 =C2=A0 see the<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; problem.=C2=A0 At best, with multiple=
 increments, reviewers may feel some<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; suspicion because they may recall som=
e folklore that such code<br>
&gt;&gt; =C2=A0 =C2=A0 is bad.<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; When the code involves multiple funct=
ion calls and unspecified<br>
&gt;&gt; =C2=A0 =C2=A0 rather<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; than undefined behavior, I doubt that=
 many reviewers will ever<br>
&gt;&gt; =C2=A0 =C2=A0 notice.<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; If anyone is interested in an actual real=
-world example...<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; Recently I wrote this bit of code:<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0if (listen(fd, 10) =3D=
=3D -1)<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0throw sy=
stem_error(errno, generic_category(), &quot;listen(&quot; +<br>
&gt;&gt; =C2=A0 =C2=A0 to_string(fd) + &quot;)&quot;);<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; This isn&#39;t a contrived example, it&#3=
9;s actual code that almost made<br>
&gt;&gt; =C2=A0 =C2=A0 it into production, written by an experienced C++ pr=
ogrammer (I&#39;ve<br>
&gt;&gt; =C2=A0 =C2=A0 been writing C++ for a living for more than 20 years=
). It wasn&#39;t<br>
&gt;&gt; =C2=A0 =C2=A0 until I started seeing some funny-looking exceptions=
 in testing that<br>
&gt;&gt; =C2=A0 =C2=A0 I realized what I&#39;d done wrong. If I hadn&#39;t =
been primed by following<br>
&gt;&gt; =C2=A0 =C2=A0 this thread I might still be scratching my head :)<b=
r>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0&gt; When this debate first showed up on this =
list I would have said I<br>
&gt;&gt; =C2=A0 =C2=A0 was mildly on the &quot;leave it undefined&quot; sid=
e, but now I&#39;m convinced<br>
&gt;&gt; =C2=A0 =C2=A0 that the &quot;define the order already and be done =
with it&quot; side is right.<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 But the only reason that code &quot;works&quot; with=
 an ltr evaluation order<br>
&gt;&gt; =C2=A0 =C2=A0 is that the parameter initialized by the impure vari=
able errno<br>
&gt;&gt; =C2=A0 =C2=A0 happens to be the leftmost parameter; if it were in =
any other<br>
&gt;&gt; =C2=A0 =C2=A0 position you would still have to copy its value into=
 a local<br>
&gt;&gt; =C2=A0 =C2=A0 variable; and indeed you still should, for clarity.<=
br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; And things will be nastier for Windows&#39; ::GetLastError since y=
ou can&#39;t<br>
&gt;&gt; even assume (via specification) which part of the standard library=
<br>
&gt;&gt; implementation will modify the underlying value. Specifying evalua=
tion<br>
&gt;&gt; order will not help. Static/thread local error codes are always tr=
icky<br>
&gt;&gt; in such case. So just avoid such style.<br>
&gt;<br>
&gt;<br>
&gt; No, GetLastError() (or WSAGetLastError(), which is what I actually cal=
l in the Windows version of this code) is effectively the same as errno in =
this context. Given guaranteed LTR evaluation, both errno and [WSA]GetLastE=
rror() would be safe, since nothing else happens between the call to listen=
() and querying the error code. The failures I saw happened because the str=
ing manipulation in the third constructor argument can modify errno if the =
compiler chooses to evaluate the arguments to system_error&#39;s constructo=
r from right to left; in a hypothetical future C++ with mandatory LTR evalu=
ation this wouldn&#39;t be a problem.<br>
&gt;</p>
<p dir=3D"ltr">You still need to ensure that &quot;nothing else happens bet=
ween the call to listen() and querying the error code&quot; - which might b=
e true for the code as presented, but can you guarantee that the access to =
errno or call to GetLastError will still be the first operand of the expres=
sion after a few months&#39; worth of commits? </p>
<p dir=3D"ltr">The difference between Windows and POSIX is that the latter =
at least specifies which standard library functions can set errno, but as t=
hat includes memory allocation and even math functions it&#39;s a guarantee=
 that isn&#39;t worth much.</p>

<p></p>

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

--001a113ecbe4d279df052e07e791--

.

------=_Part_1218_525787334.1458009077785
Content-Type: multipart/alternative;
 boundary="----=_Part_1219_144193427.1458009077785"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=883:24:32=EF=BC=8CRoss Smith=E5=86=99=E9=81=93=EF=BC=9A
>
> On 2016-03-14 20:36, FrankHB1989 wrote:=20
> >=20
> >=20
> > =E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80=
 UTC+8=E4=B8=8B=E5=8D=882:43:28=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=
=BC=9A=20
> >=20
> >=20
> >     On 13 Mar 2016 19:59, "Ross Smith" <ross....@otoy.com=20
> <javascript:>>=20
> >     wrote:=20
> >      >=20
> >      > On 2016-03-12 05:22, Hyman Rosen wrote:=20
> >      >>=20
> >      >>=20
> >      >> Even very experienced C++ programmers do not notice problems=20
> with=20
> >      >> undefined behavior due to order of evaluation, for two reasons.=
=20
> >     First,=20
> >      >> they do not remember that order of evaluation is an issue, sinc=
e=20
> >     most of=20
> >      >> the time it is not, and they do not know or remember the rules=
=20
> >     governing=20
> >      >> it.  Second, the code communicates its intent so strongly that=
=20
> it is=20
> >      >> psychologically difficult to accept that it does not do exactly=
=20
> >     what it=20
> >      >> appears to.  Recall how novel it was to accept that f(new T, ne=
w=20
> T)=20
> >      >> could leak memory even when the parameters were smart pointers.=
=20
> >      >>   (Another nail in the coffin for unspecified order, papered=20
> >     over with=20
> >      >> more accusations of bad code - "don't use new directly".)=20
> >      >>=20
> >      >> This means that the notion that such code will be weeded out by=
=20
> >     review=20
> >      >> is fatally flawed; neither the authors nor the reviewers will=
=20
> >     see the=20
> >      >> problem.  At best, with multiple increments, reviewers may feel=
=20
> some=20
> >      >> suspicion because they may recall some folklore that such code=
=20
> >     is bad.=20
> >      >> When the code involves multiple function calls and unspecified=
=20
> >     rather=20
> >      >> than undefined behavior, I doubt that many reviewers will ever=
=20
> >     notice.=20
> >      >=20
> >      >=20
> >      > If anyone is interested in an actual real-world example...=20
> >      >=20
> >      > Recently I wrote this bit of code:=20
> >      >=20
> >      >     if (listen(fd, 10) =3D=3D -1)=20
> >      >         throw system_error(errno, generic_category(), "listen(" =
+=20
> >     to_string(fd) + ")");=20
> >      >=20
> >      > This isn't a contrived example, it's actual code that almost mad=
e=20
> >     it into production, written by an experienced C++ programmer (I've=
=20
> >     been writing C++ for a living for more than 20 years). It wasn't=20
> >     until I started seeing some funny-looking exceptions in testing tha=
t=20
> >     I realized what I'd done wrong. If I hadn't been primed by followin=
g=20
> >     this thread I might still be scratching my head :)=20
> >      >=20
> >      > When this debate first showed up on this list I would have said =
I=20
> >     was mildly on the "leave it undefined" side, but now I'm convinced=
=20
> >     that the "define the order already and be done with it" side is=20
> right.=20
> >=20
> >     But the only reason that code "works" with an ltr evaluation order=
=20
> >     is that the parameter initialized by the impure variable errno=20
> >     happens to be the leftmost parameter; if it were in any other=20
> >     position you would still have to copy its value into a local=20
> >     variable; and indeed you still should, for clarity.=20
> >=20
> >=20
> > And things will be nastier for Windows' ::GetLastError since you can't=
=20
> > even assume (via specification) which part of the standard library=20
> > implementation will modify the underlying value. Specifying evaluation=
=20
> > order will not help. Static/thread local error codes are always tricky=
=20
> > in such case. So just avoid such style.=20
>
> No, GetLastError() (or WSAGetLastError(), which is what I actually call=
=20
> in the Windows version of this code) is effectively the same as errno in=
=20
> this context. Given guaranteed LTR evaluation, both errno and=20
> [WSA]GetLastError() would be safe, since nothing else happens between=20
> the call to listen() and querying the error code. The failures I saw=20
> happened because the string manipulation in the third constructor=20
> argument can modify errno if the compiler chooses to evaluate the=20
> arguments to system_error's constructor from right to left; in a=20
> hypothetical future C++ with mandatory LTR evaluation this wouldn't be a=
=20
> problem.=20
>
> Ross Smith=20
>
> In code of your version, errno and GetLastError() may be equally=20
questionable; that's basically what I said "tricky". However, in general,=
=20
the Windows case is strictly worse, because there can be almost no=20
guarantee to allow you ensure GetLastError() will actually be called or=20
not, especially when *using the standard library*. If you don't want to=20
stop using GetLastError as such subexpressions, the only way is trail and=
=20
error. On the other hand, errno is somewhat specified by ISO C++ via ISO C=
=20
(though far less clear than in POSIX), which can give you some expectations=
..
I have never bitten by errno in such case. But I was bitten by=20
GetLastError() years ago (with also iostream and some standard C routines=
=20
IIRC) because I did not realize it maybe have been called. With specified=
=20
evaluation order it would be more difficult to find such bug.
=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/a1dd0a26-b9e1-4d46-8542-503d8f36ae50%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=883:24:32=EF=BC=8CRoss 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;">On 201=
6-03-14 20:36, FrankHB1989 wrote:
<br>&gt;
<br>&gt;
<br>&gt; =E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=80 UTC+8=E4=B8=8B=E5=8D=882:43:28=EF=BC=8CEdward Catmur=E5=86=99=E9=81=
=93=EF=BC=9A
<br>&gt;
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 On 13 Mar 2016 19:59, &quot;Ross Smith&quot; &lt;<a>=
ross....@otoy.com</a> &lt;javascript:&gt;&gt;
<br>&gt; =C2=A0 =C2=A0 wrote:
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; On 2016-03-12 05:22, Hyman Rosen wrote:
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; Even very experienced C++ programmers=
 do not notice problems with
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; undefined behavior due to order of ev=
aluation, for two reasons.
<br>&gt; =C2=A0 =C2=A0 First,
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; they do not remember that order of ev=
aluation is an issue, since
<br>&gt; =C2=A0 =C2=A0 most of
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; the time it is not, and they do not k=
now or remember the rules
<br>&gt; =C2=A0 =C2=A0 governing
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; it. =C2=A0Second, the code communicat=
es its intent so strongly that it is
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; psychologically difficult to accept t=
hat it does not do exactly
<br>&gt; =C2=A0 =C2=A0 what it
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; appears to. =C2=A0Recall how novel it=
 was to accept that f(new T, new T)
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; could leak memory even when the param=
eters were smart pointers.
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; =C2=A0 (Another nail in the coffin fo=
r unspecified order, papered
<br>&gt; =C2=A0 =C2=A0 over with
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; more accusations of bad code - &quot;=
don&#39;t use new directly&quot;.)
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; This means that the notion that such =
code will be weeded out by
<br>&gt; =C2=A0 =C2=A0 review
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; is fatally flawed; neither the author=
s nor the reviewers will
<br>&gt; =C2=A0 =C2=A0 see the
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; problem. =C2=A0At best, with multiple=
 increments, reviewers may feel some
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; suspicion because they may recall som=
e folklore that such code
<br>&gt; =C2=A0 =C2=A0 is bad.
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; When the code involves multiple funct=
ion calls and unspecified
<br>&gt; =C2=A0 =C2=A0 rather
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; than undefined behavior, I doubt that=
 many reviewers will ever
<br>&gt; =C2=A0 =C2=A0 notice.
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; If anyone is interested in an actual real=
-world example...
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; Recently I wrote this bit of code:
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 if (listen(fd, 10) =3D=3D -=
1)
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw system_=
error(errno, generic_category(), &quot;listen(&quot; +
<br>&gt; =C2=A0 =C2=A0 to_string(fd) + &quot;)&quot;);
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; This isn&#39;t a contrived example, it&#3=
9;s actual code that almost made
<br>&gt; =C2=A0 =C2=A0 it into production, written by an experienced C++ pr=
ogrammer (I&#39;ve
<br>&gt; =C2=A0 =C2=A0 been writing C++ for a living for more than 20 years=
). It wasn&#39;t
<br>&gt; =C2=A0 =C2=A0 until I started seeing some funny-looking exceptions=
 in testing that
<br>&gt; =C2=A0 =C2=A0 I realized what I&#39;d done wrong. If I hadn&#39;t =
been primed by following
<br>&gt; =C2=A0 =C2=A0 this thread I might still be scratching my head :)
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; When this debate first showed up on this =
list I would have said I
<br>&gt; =C2=A0 =C2=A0 was mildly on the &quot;leave it undefined&quot; sid=
e, but now I&#39;m convinced
<br>&gt; =C2=A0 =C2=A0 that the &quot;define the order already and be done =
with it&quot; side is right.
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 But the only reason that code &quot;works&quot; with=
 an ltr evaluation order
<br>&gt; =C2=A0 =C2=A0 is that the parameter initialized by the impure vari=
able errno
<br>&gt; =C2=A0 =C2=A0 happens to be the leftmost parameter; if it were in =
any other
<br>&gt; =C2=A0 =C2=A0 position you would still have to copy its value into=
 a local
<br>&gt; =C2=A0 =C2=A0 variable; and indeed you still should, for clarity.
<br>&gt;
<br>&gt;
<br>&gt; And things will be nastier for Windows&#39; ::GetLastError since y=
ou can&#39;t
<br>&gt; even assume (via specification) which part of the standard library
<br>&gt; implementation will modify the underlying value. Specifying evalua=
tion
<br>&gt; order will not help. Static/thread local error codes are always tr=
icky
<br>&gt; in such case. So just avoid such style.
<br>
<br>No, GetLastError() (or WSAGetLastError(), which is what I actually call=
=20
<br>in the Windows version of this code) is effectively the same as errno i=
n=20
<br>this context. Given guaranteed LTR evaluation, both errno and=20
<br>[WSA]GetLastError() would be safe, since nothing else happens between=
=20
<br>the call to listen() and querying the error code. The failures I saw=20
<br>happened because the string manipulation in the third constructor=20
<br>argument can modify errno if the compiler chooses to evaluate the=20
<br>arguments to system_error&#39;s constructor from right to left; in a=20
<br>hypothetical future C++ with mandatory LTR evaluation this wouldn&#39;t=
 be a=20
<br>problem.
<br>
<br>Ross Smith
<br>
<br></blockquote><div>In code of your version, errno and GetLastError() may=
 be equally questionable; that&#39;s basically what I said &quot;tricky&quo=
t;. However, in general, the Windows case is strictly worse, because there =
can be almost no guarantee to allow you ensure GetLastError() will actually=
 be called or not, especially when <i>using the standard library</i>. If yo=
u don&#39;t want to stop using GetLastError as such subexpressions, the onl=
y way is trail and error. On the other hand, errno is somewhat specified by=
 ISO C++ via ISO C (though far less clear than in POSIX), which can give yo=
u some expectations.<br>I have never bitten by errno in such case. But I wa=
s bitten by GetLastError() years ago (with also iostream and some standard =
C routines IIRC) because I did not realize it maybe have been called. With =
specified evaluation order it would be more difficult to find such bug.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a1dd0a26-b9e1-4d46-8542-503d8f36ae50%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1dd0a26-b9e1-4d46-8542-503d8f36ae50=
%40isocpp.org</a>.<br />

------=_Part_1219_144193427.1458009077785--
------=_Part_1218_525787334.1458009077785--

.

On 2016-03-15 15:31, FrankHB1989 wrote:
>
> In code of your version, errno and GetLastError() may be equally
> questionable; that's basically what I said "tricky". However, in
> general, the Windows case is strictly worse, because there can be almost
> no guarantee to allow you ensure GetLastError() will actually be called
> or not, especially when /using the standard library/. If you don't want
> to stop using GetLastError as such subexpressions, the only way is trail
> and error. On the other hand, errno is somewhat specified by ISO C++ via
> ISO C (though far less clear than in POSIX), which can give you some
> expectations.

None of this is relevant to the issue under discussion here. Regardless
of what functions may or may not change errno or [WSA]GetLastError(),
the simple fact is that _the exact code I posted_ (not some other
hypothetical code you might come up with) was unsafe under unspecified
order of evaluation but safe if LTR is mandated. That was my entire
point. The behaviour of errno and/or GetLastError() in some completely
different code is completely irrelevant.

> I have never bitten by errno in such case. But I was bitten by
> GetLastError() years ago (with also iostream and some standard C
> routines IIRC) because I did not realize it maybe have been called. With
> specified evaluation order it would be more difficult to find such bug.

I don't understand how you can say this. If evaluation order was
specified, bugs like this would be much easier to find, because it would
either manifest itself immediately the first time the path was tested,
or would not be a bug at all.

Ross Smith

--
You received this message because you are 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/56E776E8.7070300%40otoy.com.

.

------=_Part_5735_1739447170.1458010960559
Content-Type: multipart/alternative;
 boundary="----=_Part_5736_375878742.1458010960559"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=8810:43:44=EF=BC=8CRoss Smith=E5=86=99=E9=81=93=EF=BC=9A
>
> On 2016-03-15 15:31, FrankHB1989 wrote:=20
> >=20
> > In code of your version, errno and GetLastError() may be equally=20
> > questionable; that's basically what I said "tricky". However, in=20
> > general, the Windows case is strictly worse, because there can be almos=
t=20
> > no guarantee to allow you ensure GetLastError() will actually be called=
=20
> > or not, especially when /using the standard library/. If you don't want=
=20
> > to stop using GetLastError as such subexpressions, the only way is trai=
l=20
> > and error. On the other hand, errno is somewhat specified by ISO C++ vi=
a=20
> > ISO C (though far less clear than in POSIX), which can give you some=20
> > expectations.=20
>
> None of this is relevant to the issue under discussion here. Regardless=
=20
> of what functions may or may not change errno or [WSA]GetLastError(),=20
> the simple fact is that _the exact code I posted_ (not some other=20
> hypothetical code you might come up with) was unsafe under unspecified=20
> order of evaluation but safe if LTR is mandated. That was my entire=20
> point.

This point is at least not positively related to the topic discussed here.=
=20
Changing the specification of the language does not serve code only=20
occasionally seen and "works". The example illustrated in the paper is=20
questionable because it is "popular" (sadly). However your code is not like=
=20
that. I don't think this style is debatable: it is always bad, whether you=
=20
have realized why it does not work. Before knowing the real cause, LTR or=
=20
any other specified order makes it harder to be located, or it might even=
=20
behave like a Heisenbug. After knowing the reason, this style still confuse=
=20
others. I suspect such case can be a pro to the proposal.
=20

> The behaviour of errno and/or GetLastError() in some completely=20
> different code is completely irrelevant.=20
>
> > I have never bitten by errno in such case. But I was bitten by=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/29ef620a-23b7-488e-a481-9963ca1604ea%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=8810:43:44=EF=BC=8CRoss 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;">On 201=
6-03-15 15:31, FrankHB1989 wrote:
<br>&gt;
<br>&gt; In code of your version, errno and GetLastError() may be equally
<br>&gt; questionable; that&#39;s basically what I said &quot;tricky&quot;.=
 However, in
<br>&gt; general, the Windows case is strictly worse, because there can be =
almost
<br>&gt; no guarantee to allow you ensure GetLastError() will actually be c=
alled
<br>&gt; or not, especially when /using the standard library/. If you don&#=
39;t want
<br>&gt; to stop using GetLastError as such subexpressions, the only way is=
 trail
<br>&gt; and error. On the other hand, errno is somewhat specified by ISO C=
++ via
<br>&gt; ISO C (though far less clear than in POSIX), which can give you so=
me
<br>&gt; expectations.
<br>
<br>None of this is relevant to the issue under discussion here. Regardless=
=20
<br>of what functions may or may not change errno or [WSA]GetLastError(),=
=20
<br>the simple fact is that _the exact code I posted_ (not some other=20
<br>hypothetical code you might come up with) was unsafe under unspecified=
=20
<br>order of evaluation but safe if LTR is mandated. That was my entire=20
<br>point.</blockquote><div>This point is at least not positively related t=
o the topic discussed here. Changing the specification of the language does=
 not serve code only occasionally seen and &quot;works&quot;. The example i=
llustrated in the paper is questionable because it is &quot;popular&quot; (=
sadly). However your code is not like that. I don&#39;t think this style is=
 debatable: it is always bad, whether you have realized why it does not wor=
k. Before knowing the real cause, LTR or any other specified order makes it=
 harder to be located, or it might even behave like a Heisenbug. After know=
ing the reason, this style still confuse others. I suspect such case can be=
 a pro to the proposal.<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;">The behaviour of errno and/or GetLastError() in some completely=20
<br>different code is completely irrelevant.
<br>
<br>&gt; I have never bitten by errno in such case. But I was bitten by
<br>&gt;...</blockquote></div>

<p></p>

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

------=_Part_5736_375878742.1458010960559--
------=_Part_5735_1739447170.1458010960559--

.

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

2016-03-14 16:24 GMT+03:30 FrankHB1989 <frankhb1989@gmail.com>:

>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 U=
TC+8=E4=B8=8B=E5=8D=887:10:07=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>>
>>
>> 2016-03-13 21:50 GMT+03:30 FrankHB1989 <frank...@gmail.com>:
>>
>>
>>
>> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD =
UTC+8=E4=B8=8B=E5=8D=883:55:56=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>>
>>
>> 2016-03-12 6:51 GMT+03:30 Greg Marr <greg...@gmail.com>:
>>
>> For those that haven't seen this yet:
>>
>>
>> http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meet=
ing/
>>
>> Evolution also approved the following features that were not voted in at
>> this meeting, but are currently on track for possible approval for C++17=
 at
>> our next meeting in June for inclusion in the C++17 international commen=
t
>> ballot
>>
>> Defining the order of expression evaluation to reduce portability and
>> usability bugs.
>>
>>
>> =E2=80=8BInteresting read!!!
>> By the way, has anybody mentioned that the most natural order might be
>> that of combining operators with operands(ie rules of associativity and
>> precedence)?=E2=80=8B
>>
>> Most natural? Either forget all those operators and operands, pretending
>> you are writing natural language, and let the compiler to do NLP; or use
>> some other writing system to make the need of associativity and
>> precedence away, specifically, without infix expressions, to get the
>> simplest set of order rules.
>>
>>
>> =E2=80=8BIt looks like early creators=E2=80=8B of C++ have made them eas=
y to remember. I
>> don't even think of binding order when writing compound operator
>> expressions. Because that's the first thing a C++ programmer learns and
>> practice curves it in memory.
>>
> Not so simple. Most operators are same to C. However, what about .* or
> ->*? Do they meet "natural" you said? I have seen many people surprised b=
y
> them.
>

=E2=80=8BWhat is wrong with them? =E2=80=8Bthe only matter is that novices =
who have never
heard of member pointers don't know about corresponding operators too.



>
>
>>
>>
>> All not feasible in C++. Relying on "rules of associativity and
>> precedence" is far from "natural" for users.
>>
>>
>> =E2=80=8BNothing is natural for =E2=80=8Bprogrammers; they have a tool (=
C++) and they
>> need to make with it. But it is natural to the language. Correct binding=
 of
>> operators and operators matters to any programmer; misuse of operators
>> leads to bugs and errors in simplest programs (where ordering does not
>> affect the outcome). So every programmer needs to care about precedence =
and
>> associativity:
>>
>> Are you serious? There is nothing named "binding order" of operators in
> C++.
>

Is this a discussion or an argument?
Binding order is my shorthand for precedence and associativity.



> The language itself does not mix the syntax and semantics rules at all in
> these cases. Grouping of operators and operands are specified by the
> syntax. Precedence and associativity are pure syntactic properties, and h=
ow
> to evaluate them is not related with these rules. They should be cared
> about because different forms of syntax have may different meaning, which
> cannot be determined by syntax rules solely. Correct knowledge of
> precedence and associativity is *never enough* to make an expression
> behave as you expected.
>

=E2=80=8BWhy do u keep repeating the points? I think that evaluation order =
should
follow the syntax .


>
> *(x++);
>> *x++;
>> (*x)++;
>>
>> can you tell the difference between the above lines without referring to
>> binding order? This has been the style since day  1 in C and lots code h=
as
>> been written around it. Any ordering that deviates the binding order,
>> eventually breaks existing practical well-defined code.
>>
>> How can the code still be "well-defined" if it is violating the language
> rules for decades?
>

=E2=80=8BNormally, standards statements take the most generic and compact w=
ording,
describing most possible number of cases.
Not every corner case is discussed separately. I believe that any good
statement about evaluation order should be able to describe current
behavior of simple statements without extra explanation, therefore it can't
deviate from what u might call syntactic order.


>
>
>> Separating the rules of ordering from binding adds another set of rules
>> and leads to more confusion.
>>
> Maybe. But ignorance of the difference do confused users as well. They
> eventually have to know the different sets of rules are different in
> nature. Mixing them is always artificial.
>

=E2=80=8BQuite contrary. I=E2=80=8B

=E2=80=8Bstrongly believe the separation is an artificial excuse used by so=
me
incompetent compiler =E2=80=8Bdesigners in order not to modify their design=
.. And I
also think that modern compilers already have accomplished much more
complex jobs than the discussed evaluation order, so it is not that hard to
keep up with such a modification.


>
>> Such ordering also facilitates better chaining through implicit
>> parallelism; Consider the comma operator as a left-associative operator:
>>
>> (a,b,c);
>>
>> by the time 'b' is evaluated the result of l-most comma which is 'a'
>> might actually be ready and by time 'c' is evaluated, the overall result=
 of
>> the operation might long h
>> ...
>
> If you need the order here... why not just "a; b; c;"? It is more explici=
t
> and reliable. Your expectation here is fragile, since C++ allows
> overloading of "operator,".
>

=E2=80=8BNow I believe u r arguing=E2=80=8B
..=E2=80=8B consider the right-associative assignment operator instead.


--=20
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

--=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/CALDL7dE6o%3DOEx68j2cjFasUxQT1H_d9%3DMqJuBN2WU5G=
dCC4hZg%40mail.gmail.com.

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

<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:arial na=
rrow,sans-serif;font-size:large"><br></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote"><div dir=3D"ltr">2016-03-14 16:24 GMT+03:30 Frank=
HB1989 <span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com" targe=
t=3D"_blank">frankhb1989@gmail.com</a>&gt;</span>:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-r=
ight:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><b=
r><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=80 UTC+8=E4=B8=8B=E5=8D=887:10:07=EF=BC=8CFarid Mehrabi=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"rtl"><div style=3D"font-family:arial narrow,sans-serif;font-size:large"=
><br></div><div><br><div><div dir=3D"ltr">2016-03-13 21:50 GMT+03:30 FrankH=
B1989 <span dir=3D"ltr">&lt;<a rel=3D"nofollow">frank...@gmail.com</a>&gt;<=
/span>:</div><blockquote style=3D"margin:0 .8ex;border-left:1px #ccc solid;=
border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D=
"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=
=9F=E5=85=AD UTC+8=E4=B8=8B=E5=8D=883:55:56=EF=BC=8CFarid Mehrabi=E5=86=99=
=E9=81=93=EF=BC=9A<blockquote style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"rtl"><div style=3D"font-fam=
ily:arial narrow,sans-serif;font-size:large"><br></div><div><br><div><div d=
ir=3D"ltr">2016-03-12 6:51 GMT+03:30 Greg Marr <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">greg...@gmail.com</a>&gt;</span>:</div><blockquote style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">For those that haven&#39;t seen this yet:<br><br><a href=3D"http://herb=
sutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeting/" rel=3D"n=
ofollow" target=3D"_blank">http://herbsutter.com/2016/03/11/trip-report-win=
ter-iso-c-standards-meeting/</a><br><br>Evolution also approved the followi=
ng features that were not voted in at this meeting, but are currently on tr=
ack for possible approval for C++17 at our next meeting in June for inclusi=
on in the C++17 international comment ballot<div><br>Defining the order of =
expression evaluation to reduce portability and usability bugs.</div></div>=
</blockquote></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=
=8BInteresting read!!!=C2=A0</div><div style=3D"font-family:&#39;arial narr=
ow&#39;,sans-serif;font-size:large">By the way, has anybody mentioned that =
the most natural order might be that of combining operators with operands(i=
e rules of associativity and precedence)?=E2=80=8B</div><div style=3D"font-=
family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div></div><=
/div></div></blockquote><div>Most natural? Either forget all those operator=
s and operands, pretending you are writing natural language, and let the co=
mpiler to do NLP; or use some other writing system to make the need of <spa=
n>associativity </span>and precedence away, specifically, without infix exp=
ressions, to get the simplest set of order rules. </div></div></blockquote>=
<div style=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><div st=
yle=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=
=80=8BIt looks like early creators=E2=80=8B of C++ have made them easy to r=
emember. I don&#39;t even think of binding order when writing compound oper=
ator expressions. Because that&#39;s the first thing a C++ programmer learn=
s and practice curves it in memory.</div></div></div></div></div></blockquo=
te></span><div>Not so simple. Most operators are same to C. However, what a=
bout .* or -&gt;*? Do they meet &quot;natural&quot; you said? I have seen m=
any people surprised by them.</div></div></blockquote><div style=3D"directi=
on:ltr"><br></div><div style=3D"direction:ltr"><div class=3D"gmail_default"=
 style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=
=E2=80=8BWhat is wrong with them? =E2=80=8Bthe only matter is that novices =
who have never heard of member pointers don&#39;t know about corresponding =
operators too.</div><br></div><div style=3D"direction:ltr">=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc s=
olid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div d=
ir=3D"ltr"><div>=C2=A0 <br></div><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"rtl"><div><div><div style=3D"direction:ltr">=C2=
=A0</div><blockquote style=3D"margin:0 .8ex;border-left:1px #ccc solid;bord=
er-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr=
"><div>All not feasible in C++. Relying on &quot;rules of <span>associativi=
ty and precedence&quot; is far from &quot;natural&quot; for users.</span></=
div></div></blockquote><div style=3D"direction:ltr">=C2=A0</div><div style=
=3D"direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans-se=
rif;font-size:large">=E2=80=8BNothing is natural for =E2=80=8Bprogrammers; =
they have a tool (C++) and they need to make with it. But it is natural to =
the language. Correct binding of operators and operators matters to any pro=
grammer; misuse of operators leads to bugs and errors in simplest programs =
(where ordering does not affect the outcome). So every programmer needs to =
care about precedence and associativity:</div><div style=3D"font-family:&#3=
9;arial narrow&#39;,sans-serif;font-size:large"><br></div></div></div></div=
></div></blockquote></span><div>Are you serious? There is nothing named &qu=
ot;binding order&quot; of operators in C++. </div></div></blockquote><div s=
tyle=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><div class=3D=
"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font=
-size:large">Is this a discussion or an argument?=C2=A0</div><div class=3D"=
gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large">Binding order is my shorthand for precedence and associativity.=
</div><br></div><div style=3D"direction:ltr">=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-r=
ight:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><d=
iv>The language itself does not mix the syntax and semantics rules at all i=
n these cases. Grouping of operators and operands are specified by the synt=
ax. Precedence and associativity are pure syntactic properties, and how to =
evaluate them is not related with these rules. They should be cared about b=
ecause different forms of syntax have may different meaning, which cannot b=
e determined by syntax rules solely. Correct knowledge of precedence and as=
sociativity is <i>never enough</i> to make an expression behave as you expe=
cted.<br></div></div></blockquote><div style=3D"direction:ltr"><br></div><d=
iv style=3D"direction:ltr"><div class=3D"gmail_default" style=3D"font-famil=
y:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8BWhy do u keep=
 repeating the points? I think that evaluation order should follow the synt=
ax .</div></div><div style=3D"direction:ltr">=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-r=
ight:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><d=
iv><br></div><span class=3D""><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"rtl"><div><div><div style=3D"direction:ltr"><div style=3D"font-famil=
y:&#39;arial narrow&#39;,sans-serif;font-size:large"></div><div style=3D"fo=
nt-family:&#39;arial narrow&#39;,sans-serif;font-size:large">*(x++);</div><=
div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"=
>*x++;</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;fon=
t-size:large">(*x)++;</div><div style=3D"font-family:&#39;arial narrow&#39;=
,sans-serif;font-size:large"><br></div><div style=3D"font-family:&#39;arial=
 narrow&#39;,sans-serif;font-size:large">can you tell the difference betwee=
n the above lines without referring to binding order? This has been the sty=
le since day =C2=A01 in C and lots code has been written around it. Any ord=
ering that deviates the binding order, eventually breaks existing practical=
 well-defined code.</div><div style=3D"font-family:&#39;arial narrow&#39;,s=
ans-serif;font-size:large"><br></div></div></div></div></div></blockquote><=
/span><div>How can the code still be &quot;well-defined&quot; if it is viol=
ating the language rules for decades?<br></div></div></blockquote><div styl=
e=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><div class=3D"gm=
ail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-si=
ze:large">=E2=80=8BNormally, standards statements take the most generic and=
 compact wording, describing most possible number of cases.</div><div class=
=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large">Not every corner case is discussed separately. I believe th=
at any good statement about evaluation order should be able to describe cur=
rent behavior of simple statements without extra explanation, therefore it =
can&#39;t deviate from what u might call syntactic order.</div></div><div s=
tyle=3D"direction:ltr">=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;pa=
dding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div>=C2=A0<br></div><sp=
an class=3D""><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"rtl"><div=
><div><div style=3D"direction:ltr"><div style=3D"font-family:&#39;arial nar=
row&#39;,sans-serif;font-size:large"></div><div style=3D"font-family:&#39;a=
rial narrow&#39;,sans-serif;font-size:large">Separating the rules of orderi=
ng from binding adds another set of rules and leads to more confusion.</div=
></div></div></div></div></blockquote></span><div>Maybe. But ignorance of t=
he difference do confused users as well. They eventually have to know the d=
ifferent sets of rules are different in nature. Mixing them is always artif=
icial.<br></div></div></blockquote><div style=3D"direction:ltr"><div class=
=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large;display:inline"><br></div></div><div style=3D"direction:ltr"=
><div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,s=
ans-serif;font-size:large;display:inline">=E2=80=8BQuite contrary. I=E2=80=
=8B</div>=C2=A0<div class=3D"gmail_default" style=3D"font-family:&#39;arial=
 narrow&#39;,sans-serif;font-size:large;display:inline">=E2=80=8Bstrongly b=
elieve the separation is an artificial excuse used by some incompetent comp=
iler =E2=80=8Bdesigners in order not to modify their design. And I also thi=
nk that modern compilers already have accomplished much more complex jobs t=
han the discussed evaluation order, so it is not that hard to keep up with =
such a modification.</div></div><div style=3D"direction:ltr"><div class=3D"=
gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large;display:inline"><br></div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc s=
olid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"rtl"><=
div><div><div style=3D"direction:ltr"><div style=3D"font-family:&#39;arial =
narrow&#39;,sans-serif;font-size:large">Such ordering also facilitates bett=
er chaining through implicit parallelism; Consider the comma operator as a =
left-associative operator:</div><div style=3D"font-family:&#39;arial narrow=
&#39;,sans-serif;font-size:large"><br></div><div style=3D"font-family:&#39;=
arial narrow&#39;,sans-serif;font-size:large">(a,b,c);</div><div style=3D"f=
ont-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div><di=
v style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">b=
y the time &#39;b&#39; is evaluated the result of l-most comma which is &#3=
9;a&#39; might actually be ready and by time &#39;c&#39; is evaluated, the =
overall result of the operation might long h</div></div></div></div></div><=
/span>...</blockquote><div>If you need the order here... why not just &quot=
;a; b; c;&quot;? It is more explicit and reliable. Your expectation here is=
 fragile, since C++ allows overloading of &quot;operator,&quot;.<br></div><=
/div></blockquote><div style=3D"direction:ltr"><div class=3D"gmail_default"=
 style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large;dis=
play:inline"><br></div></div><div style=3D"direction:ltr"><div class=3D"gma=
il_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-siz=
e:large;display:inline">=E2=80=8BNow I believe u r arguing=E2=80=8B</div><d=
iv class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans=
-serif;font-size:large;display:inline">.=E2=80=8B consider the right-associ=
ative assignment operator instead.</div></div><div style=3D"direction:ltr">=
<div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sa=
ns-serif;font-size:large;display:inline"><br></div></div></div><div><br></d=
iv>-- <br><div class=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"=
ltr">how am I supposed to end the twisted road of=C2=A0 your hair in such a=
 dark night??<br>unless the candle of your face does shed some light upon m=
y way!!!<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dE6o%3DOEx68j2cjFasUxQT1H_d9%3D=
MqJuBN2WU5GdCC4hZg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dE6o%3D=
OEx68j2cjFasUxQT1H_d9%3DMqJuBN2WU5GdCC4hZg%40mail.gmail.com</a>.<br />

--001a114a86969763d9052e1172ff--

.

------=_Part_11_421229695.1458028878611
Content-Type: multipart/alternative;
 boundary="----=_Part_12_892420379.1458028878612"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=883:35:58=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> 2016-03-14 16:24 GMT+03:30 FrankHB1989 <frank...@gmail.com <javascript:>>=
:
>
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 U=
TC+8=E4=B8=8B=E5=8D=887:10:07=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> 2016-03-13 21:50 GMT+03:30 FrankHB1989 <frank...@gmail.com>:
>
>
>
> =E5=9C=A8 2016=E5=B9=B43=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8B=E5=8D=883:55:56=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> 2016-03-12 6:51 GMT+03:30 Greg Marr <greg...@gmail.com>:
>
> For those that haven't seen this yet:
>
>
> http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeti=
ng/
>
> Evolution also approved the following features that were not voted in at=
=20
> this meeting, but are currently on track for possible approval for C++17 =
at=20
> our next meeting in June for inclusion in the C++17 international comment=
=20
> ballot
>
> Defining the order of expression evaluation to reduce portability and=20
> usability bugs.
>
>
> =E2=80=8BInteresting read!!!=20
> By the way, has anybody mentioned that the most natural order might be=20
> that of combining operators with operands(ie rules of associativity and=
=20
> precedence)?=E2=80=8B
>
> Most natural? Either forget all those operators and operands, pretending=
=20
> you are writing natural language, and let the compiler to do NLP; or use=
=20
> some other writing system to make the need of associativity and=20
> precedence away, specifically, without infix expressions, to get the=20
> simplest set of order rules.=20
>
>
> =E2=80=8BIt looks like early creators=E2=80=8B of C++ have made them easy=
 to remember. I=20
> don't even think of binding order when writing compound operator=20
> expressions. Because that's the first thing a C++ programmer learns and=
=20
> practice curves it in memory.
>
> Not so simple. Most operators are same to C. However, what about .* or=20
> ->*? Do they meet "natural" you said? I have seen many people surprised b=
y=20
> them.
>
> =20
>
=E2=80=8BWhat is wrong with them? =E2=80=8Bthe only matter is that novices =
who have never=20
> heard of member pointers don't know about corresponding operators too.
>
> Why (p->*f)(42) rather than p->*f(42)?=20

> =20
>
>  =20
>
> =20
>
> All not feasible in C++. Relying on "rules of associativity and=20
> precedence" is far from "natural" for users.
>
> =20
> =E2=80=8BNothing is natural for =E2=80=8Bprogrammers; they have a tool (C=
++) and they need=20
> to make with it. But it is natural to the language. Correct binding of=20
> operators and operators matters to any programmer; misuse of operators=20
> leads to bugs and errors in simplest programs (where ordering does not=20
> affect the outcome). So every programmer needs to care about precedence a=
nd=20
> associativity:
>
> Are you serious? There is nothing named "binding order" of operators in=
=20
> C++.=20
>
>
> Is this a discussion or an argument?=20
> Binding order is my shorthand for precedence and associativity.
>
> This is a statement about the fact.
Better define your terms if did not occur in the previously discussion or=
=20
the things being discussed (i.e. materials related to the papers, including=
=20
the standard).

> =20
>
> The language itself does not mix the syntax and semantics rules at all in=
=20
> these cases. Grouping of operators and operands are specified by the=20
> syntax. Precedence and associativity are pure syntactic properties, and h=
ow=20
> to evaluate them is not related with these rules. They should be cared=20
> about because different forms of syntax have may different meaning, which=
=20
> cannot be determined by syntax rules solely. Correct knowledge of=20
> precedence and associativity is *never enough* to make an expression=20
> behave as you expected.
>
>
> =E2=80=8BWhy do u keep repeating the points? I think that evaluation orde=
r should=20
> follow the syntax .
>

There is no evidence about language design can support your point. There is=
=20
evidence from the current language rules, as well as some other points of=
=20
language design (broader than the view on optimization), to support the=20
opposite point. But you (as plural) always ignore the latter, so I have to=
=20
emphasize it again.

Your point is a value judgment. The language will not be what you like just=
=20
because you think it "should" be like something. Show me your further=20
reasons, especially not discussed previously.

=20
>
>
> *(x++);
> *x++;
> (*x)++;
>
> can you tell the difference between the above lines without referring to=
=20
> binding order? This has been the style since day  1 in C and lots code ha=
s=20
> been written around it. Any ordering that deviates the binding order,=20
> eventually breaks existing practical well-defined code.
>
> How can the code still be "well-defined" if it is violating the language=
=20
> rules for decades?
>
>
> =E2=80=8BNormally, standards statements take the most generic and compact=
 wording,=20
> describing most possible number of cases.
> Not every corner case is discussed separately. I believe that any good=20
> statement about evaluation order should be able to describe current=20
> behavior of simple statements without extra explanation, therefore it can=
't=20
> deviate from what u might call syntactic order.
> =20
>
I admit the current rules of evaluation on expressions are not easy to=20
learn and use. Simplifying them is desired. However, I don't think it=20
acceptable if the change disturbs the original purpose too much: being able=
=20
to express the meaning of programs clearly. This is essentially different=
=20
to "easy" or "natural". I think it definitely comes 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/5eaffa80-a7e3-42c5-83d3-e6c6f7d638ad%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=883:35:58=EF=BC=8CFarid Mehrabi=
=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"rtl"><div style=3D"font-family:arial narrow,sans-serif;font-size:l=
arge"><br></div><div><br><div><div dir=3D"ltr">2016-03-14 16:24 GMT+03:30 F=
rankHB1989 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"pJIOJ1RZCAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">frank...@gmail.com</a>&gt;</span>:</div><blockq=
uote style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #cc=
c solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><br><br>=E5=9C=
=A8 2016=E5=B9=B43=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=
=B8=8B=E5=8D=887:10:07=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=9A<spa=
n><blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"rtl"><div style=3D"font-family:arial narrow=
,sans-serif;font-size:large"><br></div><div><br><div><div dir=3D"ltr">2016-=
03-13 21:50 GMT+03:30 FrankHB1989 <span dir=3D"ltr">&lt;<a rel=3D"nofollow"=
>frank...@gmail.com</a>&gt;</span>:</div><blockquote style=3D"margin:0 .8ex=
;border-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;pa=
dding-right:1ex"><div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=88=
12=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8B=E5=8D=883:55:56=EF=BC=
=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=9A<blockquote style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"rt=
l"><div style=3D"font-family:arial narrow,sans-serif;font-size:large"><br><=
/div><div><br><div><div dir=3D"ltr">2016-03-12 6:51 GMT+03:30 Greg Marr <sp=
an dir=3D"ltr">&lt;<a rel=3D"nofollow">greg...@gmail.com</a>&gt;</span>:</d=
iv><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">For those that haven&#39;t seen this yet:<br><=
br><a href=3D"http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-sta=
ndards-meeting/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fherbsutter.com%2F2016%2=
F03%2F11%2Ftrip-report-winter-iso-c-standards-meeting%2F\46sa\75D\46sntz\07=
51\46usg\75AFQjCNFZ3B3a9QEjcfgwYx8CEw1gJTtchA&#39;;return true;" onclick=3D=
"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fherbsutter.com=
%2F2016%2F03%2F11%2Ftrip-report-winter-iso-c-standards-meeting%2F\46sa\75D\=
46sntz\0751\46usg\75AFQjCNFZ3B3a9QEjcfgwYx8CEw1gJTtchA&#39;;return true;">h=
ttp://herbsutter.com/2016/03/<wbr>11/trip-report-winter-iso-c-<wbr>standard=
s-meeting/</a><br><br>Evolution also approved the following features that w=
ere not voted in at this meeting, but are currently on track for possible a=
pproval for C++17 at our next meeting in June for inclusion in the C++17 in=
ternational comment ballot<div><br>Defining the order of expression evaluat=
ion to reduce portability and usability bugs.</div></div></blockquote></div=
><div dir=3D"ltr"><br></div><div dir=3D"ltr"><div style=3D"font-family:&#39=
;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8BInteresting read!!!=
=C2=A0</div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;fon=
t-size:large">By the way, has anybody mentioned that the most natural order=
 might be that of combining operators with operands(ie rules of associativi=
ty and precedence)?=E2=80=8B</div><div style=3D"font-family:&#39;arial narr=
ow&#39;,sans-serif;font-size:large"><br></div></div></div></div></blockquot=
e><div>Most natural? Either forget all those operators and operands, preten=
ding you are writing natural language, and let the compiler to do NLP; or u=
se some other writing system to make the need of <span>associativity </span=
>and precedence away, specifically, without infix expressions, to get the s=
implest set of order rules. </div></div></blockquote><div style=3D"directio=
n:ltr"><br></div><div style=3D"direction:ltr"><div style=3D"font-family:&#3=
9;arial narrow&#39;,sans-serif;font-size:large">=E2=80=8BIt looks like earl=
y creators=E2=80=8B of C++ have made them easy to remember. I don&#39;t eve=
n think of binding order when writing compound operator expressions. Becaus=
e that&#39;s the first thing a C++ programmer learns and practice curves it=
 in memory.</div></div></div></div></div></blockquote></span><div>Not so si=
mple. Most operators are same to C. However, what about .* or -&gt;*? Do th=
ey meet &quot;natural&quot; you said? I have seen many people surprised by =
them.</div></div></blockquote><div>=C2=A0</div></div></div></div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"rtl"><div><div>=
<div style=3D"direction:ltr"></div><div style=3D"direction:ltr"><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=
=8BWhat is wrong with them? =E2=80=8Bthe only matter is that novices who ha=
ve never heard of member pointers don&#39;t know about corresponding operat=
ors too.</div><br></div></div></div></div></blockquote><div>Why (p-&gt;*f)(=
42) rather than p-&gt;*f(42)? <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"rtl"><div><div><div style=3D"direction:ltr"></div><di=
v style=3D"direction:ltr">=C2=A0</div><blockquote style=3D"margin:0 .8ex;bo=
rder-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;paddi=
ng-right:1ex"><div dir=3D"ltr"><div>=C2=A0 <br></div><span><blockquote styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"rtl"><div><div><div style=3D"direction:ltr">=C2=A0</div><bloc=
kquote style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #=
ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div>All not=
 feasible in C++. Relying on &quot;rules of <span>associativity and precede=
nce&quot; is far from &quot;natural&quot; for users.</span></div></div></bl=
ockquote><div style=3D"direction:ltr">=C2=A0</div><div style=3D"direction:l=
tr"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:l=
arge">=E2=80=8BNothing is natural for =E2=80=8Bprogrammers; they have a too=
l (C++) and they need to make with it. But it is natural to the language. C=
orrect binding of operators and operators matters to any programmer; misuse=
 of operators leads to bugs and errors in simplest programs (where ordering=
 does not affect the outcome). So every programmer needs to care about prec=
edence and associativity:</div><div style=3D"font-family:&#39;arial narrow&=
#39;,sans-serif;font-size:large"><br></div></div></div></div></div></blockq=
uote></span><div>Are you serious? There is nothing named &quot;binding orde=
r&quot; of operators in C++. </div></div></blockquote><div style=3D"directi=
on:ltr"><br></div><div style=3D"direction:ltr"><div style=3D"font-family:&#=
39;arial narrow&#39;,sans-serif;font-size:large">Is this a discussion or an=
 argument?=C2=A0</div><div style=3D"font-family:&#39;arial narrow&#39;,sans=
-serif;font-size:large">Binding order is my shorthand for precedence and as=
sociativity.</div><br></div></div></div></div></blockquote><div>This is a s=
tatement about the fact.<br>Better define your terms if did not occur in th=
e previously discussion or the things being discussed (i.e. materials relat=
ed to the papers, including the standard).<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"rtl"><div><div><div style=3D"direction:lt=
r"></div><div style=3D"direction:ltr">=C2=A0</div><blockquote style=3D"marg=
in:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;padding-le=
ft:1ex;padding-right:1ex"><div dir=3D"ltr"><div>The language itself does no=
t mix the syntax and semantics rules at all in these cases. Grouping of ope=
rators and operands are specified by the syntax. Precedence and associativi=
ty are pure syntactic properties, and how to evaluate them is not related w=
ith these rules. They should be cared about because different forms of synt=
ax have may different meaning, which cannot be determined by syntax rules s=
olely. Correct knowledge of precedence and associativity is <i>never enough=
</i> to make an expression behave as you expected.<br></div></div></blockqu=
ote><div style=3D"direction:ltr"><br></div><div style=3D"direction:ltr"><di=
v style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=
=E2=80=8BWhy do u keep repeating the points? I think that evaluation order =
should follow the syntax .</div></div><div style=3D"direction:ltr"></div></=
div></div></div></blockquote><div><br>There is no evidence about language d=
esign can support your point. There is evidence from the current language r=
ules, as well as some other
 points of language design (broader than the view on optimization), to supp=
ort the opposite point. But you (as plural) always ignore the latter, so I =
have to emphasize it again.<br><br>Your point is a value judgment. The lang=
uage will not be what you like just because you think it &quot;should&quot;=
 be like something. Show me your further reasons, especially not discussed =
previously.<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"rtl"><div><div><div style=3D"direction:ltr">=C2=A0</div><blockquote =
style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc sol=
id;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div><br></div><spa=
n><blockquote style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"rtl"><div><div><div style=3D"direction:ltr"=
><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:larg=
e"></div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-s=
ize:large">*(x++);</div><div style=3D"font-family:&#39;arial narrow&#39;,sa=
ns-serif;font-size:large">*x++;</div><div style=3D"font-family:&#39;arial n=
arrow&#39;,sans-serif;font-size:large">(*x)++;</div><div style=3D"font-fami=
ly:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">can you =
tell the difference between the above lines without referring to binding or=
der? This has been the style since day =C2=A01 in C and lots code has been =
written around it. Any ordering that deviates the binding order, eventually=
 breaks existing practical well-defined code.</div><div style=3D"font-famil=
y:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div></div></div>=
</div></div></blockquote></span><div>How can the code still be &quot;well-d=
efined&quot; if it is violating the language rules for decades?<br></div></=
div></blockquote><div style=3D"direction:ltr"><br></div><div style=3D"direc=
tion:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large">=E2=80=8BNormally, standards statements take the most generic a=
nd compact wording, describing most possible number of cases.</div><div sty=
le=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">Not ev=
ery corner case is discussed separately. I believe that any good statement =
about evaluation order should be able to describe current behavior of simpl=
e statements without extra explanation, therefore it can&#39;t deviate from=
 what u might call syntactic order.</div></div><div style=3D"direction:ltr"=
>=C2=A0</div></div></div></div></blockquote><div>I admit the current rules =
of evaluation on expressions are not easy to learn and use. Simplifying the=
m is desired. However, I don&#39;t think it acceptable if the change distur=
bs the original purpose too much: being able to express the meaning of prog=
rams clearly. This is essentially different to &quot;easy&quot; or &quot;na=
tural&quot;. I think it definitely comes first.<br><br> </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"rtl"><div><div><blockquote styl=
e=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;p=
adding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div>=C2=A0<br></div><s=
pan></span></div></blockquote></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5eaffa80-a7e3-42c5-83d3-e6c6f7d638ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5eaffa80-a7e3-42c5-83d3-e6c6f7d638ad=
%40isocpp.org</a>.<br />

------=_Part_12_892420379.1458028878612--
------=_Part_11_421229695.1458028878611--

.

------=_Part_462_1716619105.1458031779532
Content-Type: multipart/alternative;
 boundary="----=_Part_463_2089532220.1458031779532"

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



=E5=9C=A8 2016=E5=B9=B43=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=883:35:58=EF=BC=8CFarid Mehrabi=E5=86=99=E9=81=93=EF=BC=
=9A

> =20
>>
>>> Separating the rules of ordering from binding adds another set of rules=
=20
>>> and leads to more confusion.
>>>
>> Maybe. But ignorance of the difference do confused users as well. They=
=20
>> eventually have to know the different sets of rules are different in=20
>> nature. Mixing them is always artificial.
>>
>
> =E2=80=8BQuite contrary. I=E2=80=8B
> =20
> =E2=80=8Bstrongly believe the separation is an artificial excuse used by =
some=20
> incompetent compiler =E2=80=8Bdesigners in order not to modify their desi=
gn. And I=20
> also think that modern compilers already have accomplished much more=20
> complex jobs than the discussed evaluation order, so it is not that hard =
to=20
> keep up with such a modification.
>
> The fact is the language itself is artificial. It does nothing wrong to=
=20
add some artificial properties if they are clearly intended. To separate=20
phases is not only the successful experience of the compiler designers, but=
=20
also language designers and learners. The key point is separation of=20
concerns <https://en.wikipedia.org/wiki/Separation_of_concerns>. This=20
allows both designers, implementers and other users to study the language=
=20
in a neat way. It also makes it possible to get better architectural design=
=20
of the language implementation. These properties are general for all=20
general-purposed languages.

You found it not natural because you have not deep walk through the=20
requirements. It is true that most natural language don't need such=20
properties, but the experience for natural languages are not fir here.=20
Natural languages don't have to be implemented for conformance. They can be=
=20
tolerated to have many, many different dialects invented by every user so=
=20
there can not no precise specification to conform. The purpose of using=20
natural languages are more complicated. For these reasons, NLP can be=20
extremely hard to do right by machines. Think twice: do you indeed want=20
such unreliable implementations as your compilers/interpreters?

There are actual some negative examples of not following this methodology=
=20
in C++, notably, ambiguity resolution of some declarators. This is a=20
consequence of not splitting syntactic and semantic rules thoroughly from=
=20
the grammar. Context-free parsing is impossible. Eventually, the=20
implementations need to parse and analyze the semantics property in same=20
stage; typically they have to do many works in vain. The worse thing is, it=
=20
is also not friendly to (most of) humans. See the examples in=20
[dcl.ambig.res]; can you parse them correctly in the first glance?
=20
At last I should note that, I think there are too many phases of=20
translation in C/C++. This might be the true compromise to the historical=
=20
practice of implementations.

=20
>>
>>> Such ordering also facilitates better chaining through implicit=20
>>> parallelism; Consider the comma operator as a left-associative operator=
:
>>>
>>> (a,b,c);
>>>
>>> by the time 'b' is evaluated the result of l-most comma which is 'a'=20
>>> might actually be ready and by time 'c' is evaluated, the overall resul=
t of=20
>>> the operation might long h
>>> ...
>>
>> If you need the order here... why not just "a; b; c;"? It is more=20
>> explicit and reliable. Your expectation here is fragile, since C++ allow=
s=20
>> overloading of "operator,".
>>
>
> =E2=80=8BNow I believe u r arguing=E2=80=8B
> .=E2=80=8B consider the right-associative assignment operator instead.
>
> I don't use those assignment expressions myself, though I don't think it=
=20
is necessary to forbid such use. There are people who emphasize "only do=20
one thing and do it well" and suggest the value of assignment nonsense, but=
=20
I am not one of them. (There do exist such design for general-purposed=20
language; e.g. in Scheme, "the result of the set! expression is=20
unspecified").

>
> --=20
> how am I supposed to end the twisted road of  your hair in such a dark=20
> night??
> unless the candle of your face does shed some light upon my way!!!
>

--=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/9dd3beed-f18e-4866-bf79-97dc716dbd87%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B43=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=883:35:58=EF=BC=8CFarid Mehrabi=
=E5=86=99=E9=81=93=EF=BC=9A<br><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"rtl"><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;border-right:1px=
 #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr"><div>=C2=
=A0<br></div><span><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"rtl"=
><div><div><div style=3D"direction:ltr"><div style=3D"font-family:&#39;aria=
l narrow&#39;,sans-serif;font-size:large"></div><div style=3D"font-family:&=
#39;arial narrow&#39;,sans-serif;font-size:large">Separating the rules of o=
rdering from binding adds another set of rules and leads to more confusion.=
</div></div></div></div></div></blockquote></span><div>Maybe. But ignorance=
 of the difference do confused users as well. They eventually have to know =
the different sets of rules are different in nature. Mixing them is always =
artificial.<br></div></div></blockquote><div style=3D"direction:ltr"><div s=
tyle=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large;displ=
ay:inline"><br></div></div><div style=3D"direction:ltr"><div style=3D"font-=
family:&#39;arial narrow&#39;,sans-serif;font-size:large;display:inline">=
=E2=80=8BQuite contrary. I=E2=80=8B</div>=C2=A0<div style=3D"font-family:&#=
39;arial narrow&#39;,sans-serif;font-size:large;display:inline">=E2=80=8Bst=
rongly believe the separation is an artificial excuse used by some incompet=
ent compiler =E2=80=8Bdesigners in order not to modify their design. And I =
also think that modern compilers already have accomplished much more comple=
x jobs than the discussed evaluation order, so it is not that hard to keep =
up with such a modification.</div></div><div style=3D"direction:ltr"><div s=
tyle=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large;displ=
ay:inline"><br></div></div></div></div></div></blockquote><div>The fact is =
the language itself is artificial. It does nothing wrong to add some artifi=
cial properties if they are clearly intended. To separate phases is not onl=
y the successful experience of the compiler designers, but also language de=
signers and learners. The key point is <a href=3D"https://en.wikipedia.org/=
wiki/Separation_of_concerns">separation of concerns</a>. This allows both d=
esigners, implementers and other users to study the language in a neat way.=
 It also makes it possible to get better architectural design of the langua=
ge implementation. These properties are general for all general-purposed la=
nguages.<br><br>You found it not natural because you have not deep walk thr=
ough the requirements. It is true that most natural language don&#39;t need=
 such properties, but the experience for natural languages are not fir here=
.. Natural languages don&#39;t have to be implemented for conformance. They =
can be tolerated to have many, many different dialects invented by every us=
er so there can not no precise specification to conform. The purpose of usi=
ng natural languages are more complicated. For these reasons, NLP can be ex=
tremely hard to do right by machines. Think twice: do you indeed want such =
unreliable implementations as your compilers/interpreters?<br><br>There are=
 actual some negative examples of not following this methodology in C++, no=
tably, ambiguity resolution of some declarators. This is a consequence of n=
ot splitting syntactic and semantic rules thoroughly from the grammar. Cont=
ext-free parsing is impossible. Eventually, the implementations need to par=
se and analyze the semantics property in same stage; typically they have to=
 do many works in vain. The worse thing is, it is also not friendly to (mos=
t of) humans. See the examples in [dcl.ambig.res]; can you parse them corre=
ctly in the first glance?<br>=C2=A0<br>At last I should note that, I think =
there are too many phases of translation in C/C++. This might be the true c=
ompromise to the historical practice of implementations.<br><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"rtl"><div><div class=3D=
"gmail_quote"><div style=3D"direction:ltr"><div style=3D"font-family:&#39;a=
rial narrow&#39;,sans-serif;font-size:large;display:inline"></div></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc =
solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div =
dir=3D"ltr"><div>=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"><span>=
<div dir=3D"rtl"><div><div><div style=3D"direction:ltr"><div style=3D"font-=
family:&#39;arial narrow&#39;,sans-serif;font-size:large">Such ordering als=
o facilitates better chaining through implicit parallelism; Consider the co=
mma operator as a left-associative operator:</div><div style=3D"font-family=
:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></div><div style=3D=
"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">(a,b,c);</d=
iv><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:la=
rge"><br></div><div style=3D"font-family:&#39;arial narrow&#39;,sans-serif;=
font-size:large">by the time &#39;b&#39; is evaluated the result of l-most =
comma which is &#39;a&#39; might actually be ready and by time &#39;c&#39; =
is evaluated, the overall result of the operation might long h</div></div><=
/div></div></div></span>...</blockquote><div>If you need the order here... =
why not just &quot;a; b; c;&quot;? It is more explicit and reliable. Your e=
xpectation here is fragile, since C++ allows overloading of &quot;operator,=
&quot;.<br></div></div></blockquote><div style=3D"direction:ltr"><div style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large;display:i=
nline"><br></div></div><div style=3D"direction:ltr"><div style=3D"font-fami=
ly:&#39;arial narrow&#39;,sans-serif;font-size:large;display:inline">=E2=80=
=8BNow I believe u r arguing=E2=80=8B</div><div style=3D"font-family:&#39;a=
rial narrow&#39;,sans-serif;font-size:large;display:inline">.=E2=80=8B cons=
ider the right-associative assignment operator instead.</div></div><div sty=
le=3D"direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans-=
serif;font-size:large;display:inline"><br></div></div></div></div></div></b=
lockquote><div>I don&#39;t use those assignment expressions myself, though =
I don&#39;t think it is necessary to forbid such use. There are people who =
emphasize &quot;only do one thing and do it well&quot; and suggest the valu=
e of assignment nonsense, but I am not one of them. (There do exist such de=
sign for general-purposed language; e.g. in Scheme, &quot;the result of the=
 set! expression is unspecified&quot;).<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"rtl"><div><div class=3D"gmail_quote"><div st=
yle=3D"direction:ltr"><div style=3D"font-family:&#39;arial narrow&#39;,sans=
-serif;font-size:large;display:inline"></div></div></div><div><br></div>-- =
<br><div><div dir=3D"rtl"><div><div dir=3D"ltr">how am I supposed to end th=
e twisted road of=C2=A0 your hair in such a dark night??<br>unless the cand=
le of your face does shed some light upon my way!!!<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9dd3beed-f18e-4866-bf79-97dc716dbd87%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9dd3beed-f18e-4866-bf79-97dc716dbd87=
%40isocpp.org</a>.<br />

------=_Part_463_2089532220.1458031779532--
------=_Part_462_1716619105.1458031779532--

.

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

On Mon, Mar 14, 2016 at 7:09 AM, Farid Mehrabi <farid.mehrabi@gmail.com>
wrote:
>
> cout << (x=3) << x-- << x-- << x;
>
> Since post-dec operator is more precedent than l-shift, the expected
> output will be 3321.
>
Other evaluation orders wouldn't lead to pleasant outputs.
>

I assume you're being prescriptive (that is, saying what this expression
should yield
as opposed to what it does yield) - by current language rules, this
expression has
undefined behavior.

But I don't understand what precedence has to do with anything.  The
expression is
a tree of unary and binary operations.  Regardless of the precedence and
associativity
of the operations, proper evaluation consists simply of evaluating the left
(or only)
operand, then the right operand if present, then applying the operation.
This ordering
is best described as strict left-to-right , and precedence and
associativity don't need to
be mentioned at all.

That is, precedence and associativity tell you how to construct the
expression tree.
Order of evaluation tells you how to process the expression tree.  For
multiple
assignments a() = b() = c(), associativity tells you that the resulting
expression
tree is a() = (b() = c()).  When you evaluate this tree, it simply consists
of
function calls and binary assignment operators, and there is no reason to
evaluate
the right operand of a binary assignment operator before the left one, so
the order of
evaluation should be a(), b(), c(), assign to result of b(), assign to
result of a().

--
You received this message because you are 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/CAHSYqdZfhfNuj4SBVa9MEm3YisEyWDhMnWZGPKGiePzeohS%3DgQ%40mail.gmail.com.

--001a1142419abd5ef0052e186fdf
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, Mar 14, 2016 at 7:09 AM, Farid Mehrabi <span dir=3D"ltr">&lt;<a href=3D=
"mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.com<=
/a>&gt;</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"rtl"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><div style=3D"direction:ltr=
"><div><font face=3D"arial, helvetica, sans-serif">cout &lt;&lt; (x=3D3) &l=
t;&lt; x-- &lt;&lt; x-- &lt;&lt; x;<br></font></div><div><font face=3D"aria=
l, helvetica, sans-serif"><br></font></div><div><font face=3D"arial, helvet=
ica, sans-serif">Since post-dec operator is more precedent than l-shift, th=
e expected output will be 3321.</font></div></div></div></div></div></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"rtl"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div style=3D"direction:ltr"><div><font fa=
ce=3D"arial, helvetica, sans-serif">Other evaluation orders wouldn&#39;t le=
ad to pleasant outputs.</font></div></div></div></div></div></blockquote><d=
iv><br>I assume you&#39;re being prescriptive (that is, saying what this ex=
pression should yield<br>as opposed to what it does yield) - by current lan=
guage rules, this expression has<br>undefined behavior.<br><br>But I don&#3=
9;t understand what precedence has to do with anything.=C2=A0 The expressio=
n=C2=A0is<br>a tree of unary and binary operations.=C2=A0 Regardless of the=
 precedence and associativity<br>of the operations, proper evaluation consi=
sts simply of evaluating the left (or only)<br>operand, then the right oper=
and if present, then applying the operation.=C2=A0 This ordering<br>is best=
 described as strict left-to-right , and precedence and associativity don&#=
39;t need to<br>be mentioned at all.<br><br>That is, precedence and associa=
tivity tell you how to construct the expression tree.<br>Order of evaluatio=
n tells you how to process the expression tree.=C2=A0 For multiple<br>assig=
nments=C2=A0<font face=3D"monospace, monospace">a() =3D b() =3D c()</font>,=
 associativity tells you that the resulting expression<br>tree is <font fac=
e=3D"monospace, monospace">a() =3D (b() =3D c())</font>.=C2=A0 When you eva=
luate this tree, it simply consists of<br>function calls and binary assignm=
ent operators, and there is no reason to evaluate</div><div>the right=C2=A0=
operand of a binary assignment operator before the left one, so the order o=
f<br>evaluation should be <font face=3D"monospace, monospace">a()</font>, <=
font face=3D"monospace, monospace">b()</font>, <font face=3D"monospace, mon=
ospace">c()</font>, assign to result of <font face=3D"monospace, monospace"=
>b()</font>, assign to result of <font face=3D"monospace, monospace">a()</f=
ont>.</div><div><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZfhfNuj4SBVa9MEm3YisEyWDhMnWZG=
PKGiePzeohS%3DgQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZfhfNuj4=
SBVa9MEm3YisEyWDhMnWZGPKGiePzeohS%3DgQ%40mail.gmail.com</a>.<br />

--001a1142419abd5ef0052e186fdf--

.