------=_Part_1518_374820337.1447965745461
Content-Type: multipart/alternative;
 boundary="----=_Part_1519_1983590295.1447965745461"

------=_Part_1519_1983590295.1447965745461
Content-Type: text/plain; charset=UTF-8

On Thursday, November 19, 2015 at 12:24:51 PM UTC-8, Kazutoshi SATODA wrote:
>
> But I think the above mentioned prohibition of transformation is general
> issue, not only on older machine architectures, and can be noticeable
> performance difference.
>
> Is these kind of concern already discussed?
>
>
I doubt my opinion matters, but personally, I'd rather have a correct
program than a fast one.

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_1519_1983590295.1447965745461
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, November 19, 2015 at 12:24:51 PM UTC-8, Kazut=
oshi SATODA wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">But I think =
the above mentioned prohibition of transformation is general
<br>issue, not only on older machine architectures, and can be noticeable
<br>performance difference.
<br>
<br>Is these kind of concern already discussed?
<br>
<br></blockquote><div><br>I doubt my opinion matters, but personally, I&#39=
;d rather have a correct program than a fast one.<br><br>Melissa <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_1519_1983590295.1447965745461--
------=_Part_1518_374820337.1447965745461--

.

------=_Part_1205_293810995.1447966327299
Content-Type: multipart/alternative;
 boundary="----=_Part_1206_943839077.1447966327299"

------=_Part_1206_943839077.1447966327299
Content-Type: text/plain; charset=UTF-8

On Thursday, November 19, 2015 at 3:24:51 PM UTC-5, Kazutoshi SATODA wrote:
>
> P0145R0: Refining Expression Evaluation Order for Idiomatic C++ (Revision
> 1)
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf
> > In summary, the following expressions are evaluated in the order
> > a, then b, then c, then d:
> ...
> >     3. a(b, c, d)
>
> I have thought of a pattern where specifying evaluation order of
> function arguments can result in general and noticeable prohibition
> of some compiler optimizations.
> (I'm afraid of that this is already discussed, or I'm just writing
>  something silly. I'm not a compiler writer, and the paper should
>  have been reviewed by some compiler writers...)
>

Gabriel Dos Reis and Jonathan Caves work on Visual C++, if I'm not mistaken.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_1206_943839077.1447966327299
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, November 19, 2015 at 3:24:51 PM UTC-5, Kazutoshi SATODA wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">P0145R0: Refining Expression E=
valuation Order for Idiomatic C++ (Revision 1)
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p014=
5r0.pdf" 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%=
2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0145r0.pdf\46sa\75D\46sntz\0751\46usg\75AF=
QjCNEbZmJOL_yEiq8zVZJqtZDlIWhk2w&#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%2Fp0145r0.pdf\46sa\75D\46sntz\0751\46usg\=
75AFQjCNEbZmJOL_yEiq8zVZJqtZDlIWhk2w&#39;;return true;">http://www.open-std=
..org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0145r0.pdf</a>
<br>&gt; In summary, the following expressions are evaluated in the order
<br>&gt; a, then b, then c, then d:
<br>...
<br>&gt; =C2=A0 =C2=A0 3. a(b, c, d)
<br>
<br>I have thought of a pattern where specifying evaluation order of
<br>function arguments can result in general and noticeable prohibition
<br>of some compiler optimizations.
<br>(I&#39;m afraid of that this is already discussed, or I&#39;m just writ=
ing
<br>=C2=A0something silly. I&#39;m not a compiler writer, and the paper sho=
uld
<br>=C2=A0have been reviewed by some compiler writers...)
<br></blockquote><div><br>Gabriel Dos Reis and Jonathan Caves work on Visua=
l C++, if I&#39;m not mistaken.<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_1206_943839077.1447966327299--
------=_Part_1205_293810995.1447966327299--

.

------=_Part_27_1764862292.1447966435900
Content-Type: multipart/alternative;
 boundary="----=_Part_28_1699025070.1447966435901"

------=_Part_28_1699025070.1447966435901
Content-Type: text/plain; charset=UTF-8

On Thursday, November 19, 2015 at 3:42:25 PM UTC-5, Myriachan wrote:
>
> On Thursday, November 19, 2015 at 12:24:51 PM UTC-8, Kazutoshi SATODA
> wrote:
>>
>> But I think the above mentioned prohibition of transformation is general
>> issue, not only on older machine architectures, and can be noticeable
>> performance difference.
>>
>> Is these kind of concern already discussed?
>>
>>
> I doubt my opinion matters, but personally, I'd rather have a correct
> program than a fast one.
>

There are plenty of languages that ensure correctness; nobody's forcing you
to use C++.

We shouldn't dismiss performance concerns for something like this
out-of-hand. It would instead be better to prove that these concerns are
going to be a non-trivial 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_28_1699025070.1447966435901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, November 19, 2015 at 3:42:25 PM UTC-5, Myriac=
han 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 =
Thursday, November 19, 2015 at 12:24:51 PM UTC-8, Kazutoshi SATODA wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">But I think the above mentioned prohi=
bition of transformation is general
<br>issue, not only on older machine architectures, and can be noticeable
<br>performance difference.
<br>
<br>Is these kind of concern already discussed?
<br>
<br></blockquote><div><br>I doubt my opinion matters, but personally, I&#39=
;d rather have a correct program than a fast one.<br></div></div></blockquo=
te><div><br>There are plenty of languages that ensure correctness; nobody&#=
39;s forcing you to use C++.<br><br>We shouldn&#39;t dismiss performance co=
ncerns for something like this out-of-hand. It would instead be better to p=
rove that these concerns are going to be a non-trivial problem.<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_28_1699025070.1447966435901--
------=_Part_27_1764862292.1447966435900--

.

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

We shouldn=E2=80=99t assume that the authors of the proposal are insensitiv=
e to performance reasons.
We are longtime C++ designers and implementers, very much attune to the ess=
ence of C++.

However, when writing a correct program has become difficult and common idi=
oms have become traps and not supported by the language rules, we must reas=
sess our design criteria and revise the rules as necessary.  Please see the=
 statement of the problem in the paper.  A programming language is a set of=
 responses to the problems of its time.
As has been pointed our repeatedly, the example code

void f()
{
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
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);
assert(s =3D=3D =E2=80=9CI have heard it works only if you believe in it=E2=
=80=9D);
}

was published in Bjarne=E2=80=99s book TC++PL4.  Before publication, that p=
articular code was reviewed by world wide leading C++ experts (at least a d=
ozen, if my memory serves me correctly, the majority of whom attend C++ sta=
ndards meetings and make contributions.)

Interesting enough, the week just before the Kona meeting, an esteemed coll=
eague of mine and I spent a day and half chasing an obscure bug (in a real =
product) that turned out to be an OEE issue on a very simple-looking code. =
 Worse: the offending code was authored by myself =E2=98=B9

-- Gaby

From: Nicol Bolas [mailto:jmckesson@gmail.com]
Sent: Thursday, November 19, 2015 12:54 PM
To: ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>
Cc: Gabriel Dos Reis <gdr@microsoft.com>
Subject: Re: Concerns on specifying evaluation order of function arguments =
(P0145R0)

On Thursday, November 19, 2015 at 3:42:25 PM UTC-5, Myriachan wrote:
On Thursday, November 19, 2015 at 12:24:51 PM UTC-8, Kazutoshi SATODA wrote=
:
But I think the above mentioned prohibition of transformation is general
issue, not only on older machine architectures, and can be noticeable
performance difference.

Is these kind of concern already discussed?

I doubt my opinion matters, but personally, I'd rather have a correct progr=
am than a fast one.

There are plenty of languages that ensure correctness; nobody's forcing you=
 to use C++.

We shouldn't dismiss performance concerns for something like this out-of-ha=
nd. It would instead be better to prove that these concerns are going to be=
 a non-trivial problem.

--=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/.

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
 {font-family:Wingdings;
 panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
 {font-family:"Cambria Math";
 panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
 {font-family:Calibri;
 panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
 {font-family:Consolas;
 panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
 {margin:0in;
 margin-bottom:.0001pt;
 font-size:12.0pt;
 font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
 {mso-style-priority:99;
 color:#0563C1;
 text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
 {mso-style-priority:99;
 color:#954F72;
 text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
 {mso-style-name:msonormal;
 mso-margin-top-alt:auto;
 margin-right:0in;
 mso-margin-bottom-alt:auto;
 margin-left:0in;
 font-size:12.0pt;
 font-family:"Times New Roman",serif;}
span.EmailStyle18
 {mso-style-type:personal-reply;
 font-family:"Calibri",sans-serif;
 color:#1F497D;}
..MsoChpDefault
 {mso-style-type:export-only;
 font-family:"Calibri",sans-serif;}
@page WordSection1
 {size:8.5in 11.0in;
 margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
 {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">We shouldn=E2=80=99t assume that the =
authors of the proposal are insensitive to performance reasons.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">We are longtime C&#43;&#43; designers=
 and implementers, very much attune to the essence of C&#43;&#43;.<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">However, when writing a correct progr=
am has become difficult and common idioms have become traps and not support=
ed by the language rules, we must reassess our
 design criteria and revise the rules as necessary.&nbsp; Please see the st=
atement of the problem in the paper.&nbsp; A programming language is a set =
of responses to the problems of its time.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">As has been pointed our repeatedly, t=
he example code<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
13.0pt;font-family:Consolas">void f()
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
13.0pt;font-family:Consolas">{<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:1.0in"><span style=3D"font-size=
:13.0pt;font-family:Consolas">std::string s =3D =E2=80=9Cbut I have heard i=
t works even if you don=E2=80=99t believe in it=E2=80=9D<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"margin-left:1.0in"><span style=3D"font-size=
:13.0pt;font-family:Consolas">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);<o:p></o:p></span=
></p>
<p class=3D"MsoNormal" style=3D"margin-left:1.0in"><span style=3D"font-size=
:13.0pt;font-family:Consolas">assert(s =3D=3D =E2=80=9CI have heard it work=
s only if you believe in it=E2=80=9D);<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
11.0pt;font-family:Consolas;color:#1F497D">}<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">was published in Bjarne=E2=80=99s boo=
k TC&#43;&#43;PL4.&nbsp; Before publication, that particular code was revie=
wed by world wide leading C&#43;&#43; experts (at least a dozen, if my memo=
ry
 serves me correctly, the majority of whom attend C&#43;&#43; standards mee=
tings and make contributions.)&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Interesting enough, the week just bef=
ore the Kona meeting, an esteemed colleague of mine and I spent a day and h=
alf chasing an obscure bug (in a real product)
 that turned out to be an OEE issue on a very simple-looking code.&nbsp; Wo=
rse: the offending code was authored by myself
</span><span style=3D"font-size:11.0pt;font-family:Wingdings;color:#1F497D"=
>L</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sa=
ns-serif;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">-- Gaby<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> Nicol Bolas [mailto:jmckesson@=
gmail.com]
<br>
<b>Sent:</b> Thursday, November 19, 2015 12:54 PM<br>
<b>To:</b> ISO C&#43;&#43; Standard - Future Proposals &lt;std-proposals@is=
ocpp.org&gt;<br>
<b>Cc:</b> Gabriel Dos Reis &lt;gdr@microsoft.com&gt;<br>
<b>Subject:</b> Re: Concerns on specifying evaluation order of function arg=
uments (P0145R0)<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal">On Thursday, November 19, 2015 at 3:42:25 PM UTC-5, =
Myriachan wrote:<o:p></o:p></p>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class=3D"MsoNormal">On Thursday, November 19, 2015 at 12:24:51 PM UTC-8,=
 Kazutoshi SATODA wrote:<o:p></o:p></p>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">But I think the above=
 mentioned prohibition of transformation is general
<br>
issue, not only on older machine architectures, and can be noticeable <br>
performance difference. <br>
<br>
Is these kind of concern already discussed? <o:p></o:p></p>
</blockquote>
<div>
<p class=3D"MsoNormal"><br>
I doubt my opinion matters, but personally, I'd rather have a correct progr=
am than a fast one.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><br>
There are plenty of languages that ensure correctness; nobody's forcing you=
 to use C&#43;&#43;.<br>
<br>
We shouldn't dismiss performance concerns for something like this out-of-ha=
nd. It would instead be better to prove that these concerns are going to be=
 a non-trivial problem.<o:p></o:p></p>
</div>
</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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--_000_BLUPR03MB117DE5C77F8DC2333C23177B01B0BLUPR03MB117namprd_--

.

On 2015/11/20 5:24 +0900, Kazutoshi Satoda wrote:
> Consider the following transformation from g() to g_transformed():
>
>   int f(int a1, int a2, int a3);
>   int pure(int);
>   int non_local;
>
>   int g(int (*unknown)())
>   {
>     return f(pure(non_local), unknown(), pure(non_local));
>   }
>
>   int g_transformed(int (*unknown)())
>   {
>     int temp = pure(non_local);
>     return f(temp, unknown(), temp);
>   }
>
> Assuming that the compiler can detect or be informed that pure() is a
> pure function (it returns a value depending only on its arguments), this
> transformation is valid as optimization because the compiler is allowed
> to choose the evaluation order as (a1 -> a3 -> a2) so that it can be
> proven that two evaluations of "pure(non_local)" produce a same value.

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
GCC is smarter than me, as it knows that calling unknown() first is even
better.


For function attributes on GCC:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
> const
>   Many functions do not examine any values except their arguments, and
>   have no effects except the return value. Basically this is just
>   slightly more strict class than the pure attribute below, since
>   function is not allowed to read global memory.

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

.

| I got an evidence that GCC (5.2, and also 4.4) actually does this kind of
| transformation with "int pure(int) __attribute__((const))".

When the arguments are, the compiler knows it can invoke the "as if" rule a=
nd reorder as it pleases -- there is no way to tell.

Note that the issue isn't that there won't be difference in codegen (that a=
ctually is the whole point of the proposal.)  The question is whether any  =
additional overhead is measurable in typical scenario and if so whether it =
is tolerable compared to alternatives (the traps we have today.)

I expect compilers to also offer switches for non-standard evaluation order=
, just like some have -funsafe-math.

PS: I worked on GCC for at least 16 years :-)

-- Gaby

--=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/.

.

On Thu, Nov 19, 2015 at 3:08 PM, Gabriel Dos Reis <gdr@microsoft.com> wrote=
:
> As has been pointed our repeatedly, the example code
>
>
>
> void f()
>
> {
>
> 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
>
> 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);
>
> assert(s =3D=3D =E2=80=9CI have heard it works only if you believe in it=
=E2=80=9D);
>
> }

For this particular case, I personally don't think that we have to
make it work.  In many languages, it works because the string
is immutable and `.replace` is creating new objects.  IMHO,
referring a mutated object more than once in a sequence of
operations in a statement is a bad idea in general, not just in
C++.

That_map[] example subscribes to the same problem, since []
is an mutating operation in C++ but non-mutating in many other
languages.  In my own code, [] of map-like objects is non-
mutating and users are forced to use named member function
for inserting or updating.  That's my 0.02.

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--=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/.

.

--089e012952feaf821f0524ecb457
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 19, 2015 at 2:40 PM, Zhihao Yuan <zy@miator.net> wrote:
>
> For this particular case, I personally don't think that we have to
> make it work.  In many languages, it works because the string
> is immutable and `.replace` is creating new objects.  IMHO,
> referring a mutated object more than once in a sequence of
> operations in a statement is a bad idea in general, not just in
> C++.


I think this is what bothers me most. That we'd be potentially preventing
certain optimizations is one thing, but separate from that is that by
defining the code and its ordering, we'd be effectively *sanctioning* the
dependence on it by users. This is at least a little bit scary. We'd be
changing incorrect code to "correct" but subtle code (of course, the fact
that it is currently invalid is also sometimes subtle).

I don't have a strong opinion either way, but I do agree that this is an
important point that shouldn't be overlooked.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--089e012952feaf821f0524ecb457
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, Nov 19, 2015 at 2:40 PM, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;</span> wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">For this particular case, I personally don&#3=
9;t think that we have to<br>
make it work.=C2=A0 In many languages, it works because the string<br>
is immutable and `.replace` is creating new objects.=C2=A0 IMHO,<br>
referring a mutated object more than once in a sequence of<br>
operations in a statement is a bad idea in general, not just in<br>
C++.</blockquote><div><br></div><div>I think this is what bothers me most. =
That we&#39;d be potentially preventing certain optimizations is one thing,=
 but separate from that is that by defining the code and its ordering, we&#=
39;d be effectively <i>sanctioning</i> the dependence on it by users. This =
is at least a little bit scary. We&#39;d be changing incorrect code to &quo=
t;correct&quot; but subtle code (of course, the fact that it is currently i=
nvalid is also sometimes subtle).</div><div><br></div><div>I don&#39;t have=
 a strong opinion either way, but I do agree that this is an important poin=
t that shouldn&#39;t be overlooked.</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 />

--089e012952feaf821f0524ecb457--

.

------=_Part_1454_466469904.1447977173821
Content-Type: multipart/alternative;
 boundary="----=_Part_1455_2066284598.1447977173821"

------=_Part_1455_2066284598.1447977173821
Content-Type: text/plain; charset=UTF-8

On Thursday, November 19, 2015 at 5:59:07 PM UTC-5, Matt Calabrese wrote:
>
> On Thu, Nov 19, 2015 at 2:40 PM, Zhihao Yuan <z...@miator.net
> <javascript:>> wrote:
>>
>> For this particular case, I personally don't think that we have to
>> make it work.  In many languages, it works because the string
>> is immutable and `.replace` is creating new objects.  IMHO,
>> referring a mutated object more than once in a sequence of
>> operations in a statement is a bad idea in general, not just in
>> C++.
>
>
> I think this is what bothers me most. That we'd be potentially preventing
> certain optimizations is one thing, but separate from that is that by
> defining the code and its ordering, we'd be effectively *sanctioning* the
> dependence on it by users. This is at least a little bit scary. We'd be
> changing incorrect code to "correct" but subtle code (of course, the fact
> that it is currently invalid is also sometimes subtle).
>
> I don't have a strong opinion either way, but I do agree that this is an
> important point that shouldn't be overlooked.
>

Here's the problem. We have three choices:

1) The status quo. That is, we encourage the writing of such code (having
functions that return references to `this` encourages it) while
simultaneously making it very difficult for a user to know that they've
written something incorrect relative to the standard. At best, we can hope
for static analysis tools to step in and say "Hey, you did something
possibly wrong here." At worse, users write subtle bugs into their programs
that only appear on platforms that happen to use a different evaluation
order.

2) Change std::string and various other modifiable types so that they're
non-modifiable, thus breaking tons of perfectly valid (and reasonably
performing) code that has already been written. Note that it will only fix
this particular kind of issue, not the other problems that come from order
of evaluation issues.

3) Change the rules of evaluation so that users can know that what they've
written is actually valid C++ code.

The status quo helps *nobody*. And changing existing classes to be
non-modifiable is a non-starter. So the only way to address the problem at
all is to fix the order of evaluation of things.

Sure, people will still be able to write such unfortunate code. But
backwards compatibility, and resistance to against immutable types in
general from C++ programmers, means that it's just not going to happen.
Better to focus on the solution that's actually possible than the ones that
aren't.

--

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

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

On Thursday, November 19, 2015 at 5:59:07 PM UTC-5, Matt Calabrese wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Thu, Nov 19, 2015 at 2:40 PM, Zhihao Yuan <span dir=3D"=
ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"eJJVUqkOBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">z...@miator.net</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For=
 this particular case, I personally don&#39;t think that we have to<br>
make it work.=C2=A0 In many languages, it works because the string<br>
is immutable and `.replace` is creating new objects.=C2=A0 IMHO,<br>
referring a mutated object more than once in a sequence of<br>
operations in a statement is a bad idea in general, not just in<br>
C++.</blockquote><div><br></div><div>I think this is what bothers me most. =
That we&#39;d be potentially preventing certain optimizations is one thing,=
 but separate from that is that by defining the code and its ordering, we&#=
39;d be effectively <i>sanctioning</i> the dependence on it by users. This =
is at least a little bit scary. We&#39;d be changing incorrect code to &quo=
t;correct&quot; but subtle code (of course, the fact that it is currently i=
nvalid is also sometimes subtle).</div><div><br></div><div>I don&#39;t have=
 a strong opinion either way, but I do agree that this is an important poin=
t that shouldn&#39;t be overlooked.</div></div></div></div></blockquote><di=
v><br>Here&#39;s the problem. We have three choices:<br><br>1) The status q=
uo. That is, we encourage the writing of such code (having functions that r=
eturn references to `this` encourages it) while simultaneously making it ve=
ry difficult for a user to know that they&#39;ve written something incorrec=
t relative to the standard. At best, we can hope for static analysis tools =
to step in and say &quot;Hey, you did something possibly wrong here.&quot; =
At worse, users write subtle bugs into their programs that only appear on p=
latforms that happen to use a different evaluation order.<br><br>2) Change =
std::string and various other modifiable types so that they&#39;re non-modi=
fiable, thus breaking tons of perfectly valid (and reasonably performing) c=
ode that has already been written. Note that it will only fix this particul=
ar kind of issue, not the other problems that come from order of evaluation=
 issues.<br><br>3) Change the rules of evaluation so that users can know th=
at what they&#39;ve written is actually valid C++ code.<br><br>The status q=
uo helps <i>nobody</i>. And changing existing classes to be non-modifiable =
is a non-starter. So the only way to address the problem at all is to fix t=
he order of evaluation of things.<br><br>Sure, people will still be able to=
 write such unfortunate code. But backwards compatibility, and resistance t=
o against immutable types in general from C++ programmers, means that it&#3=
9;s just not going to happen. Better to focus on the solution that&#39;s ac=
tually possible than the ones that aren&#39;t.<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_1455_2066284598.1447977173821--
------=_Part_1454_466469904.1447977173821--

.

On Thu, Nov 19, 2015 at 5:52 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> 1) The status quo. That is, we encourage the writing of such code (having
> functions that return references to `this` encourages it) while
> simultaneously making it very difficult for a user to know that they've
> written something incorrect relative to the standard.

Chaining style is good, but the sample code is more like lasagna -- it
referred the chained target again in the argument list.  If string has a
member function called `find_and_replace`, the problem will go away,
and the code will be cleaner; a free function has the same effect, just
without chaining.  This is because `find` will be enclosed in the function
body, so it will be evaluated before the next pair of `find` & `replace` call.

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

.

------=_Part_2058_1668495052.1448018172772
Content-Type: multipart/alternative;
 boundary="----=_Part_2059_804816051.1448018172772"

------=_Part_2059_804816051.1448018172772
Content-Type: text/plain; charset=UTF-8

On Thursday, 19 November 2015 23:52:54 UTC, Nicol Bolas wrote:
>
> Here's the problem. We have three choices:
>
> 1) The status quo. That is, we encourage the writing of such code (having
> functions that return references to `this` encourages it) while
> simultaneously making it very difficult for a user to know that they've
> written something incorrect relative to the standard. At best, we can hope
> for static analysis tools to step in and say "Hey, you did something
> possibly wrong here." At worse, users write subtle bugs into their programs
> that only appear on platforms that happen to use a different evaluation
> order.
>
> 2) Change std::string and various other modifiable types so that they're
> non-modifiable, thus breaking tons of perfectly valid (and reasonably
> performing) code that has already been written. Note that it will only fix
> this particular kind of issue, not the other problems that come from order
> of evaluation issues.
>
> 3) Change the rules of evaluation so that users can know that what they've
> written is actually valid C++ code.
>

Yes, let's change the rules to more closely match what users expect, but I
don't believe that expectation exists for function arguments specifically;
that is, "everyone knows" that function arguments are evaluated in
indeterminate order. This feels intuitive because (as with, say, addition)
the syntax does not imply any dependency between arguments separated by a
syntactic comma.

Note that I'm fine with sequencing the postfix-expression result and object
parameter (if any) before the arguments proper. Doing so would fix the
"chaining" example without impacting Kazutoshi's motivating example.

Also, if overloaded operators are evaluated according to the corresponding
built-in operator (rather than as a function call) then that removes a
major motivation for changing the rules for function calls.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_2059_804816051.1448018172772
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, 19 November 2015 23:52:54 UTC, Nicol Bolas  wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div>Here&#39;s the problem. We have three=
 choices:<br><br>1) The status quo. That is, we encourage the writing of su=
ch code (having functions that return references to `this` encourages it) w=
hile simultaneously making it very difficult for a user to know that they&#=
39;ve written something incorrect relative to the standard. At best, we can=
 hope for static analysis tools to step in and say &quot;Hey, you did somet=
hing possibly wrong here.&quot; At worse, users write subtle bugs into thei=
r programs that only appear on platforms that happen to use a different eva=
luation order.<br><br>2) Change std::string and various other modifiable ty=
pes so that they&#39;re non-modifiable, thus breaking tons of perfectly val=
id (and reasonably performing) code that has already been written. Note tha=
t it will only fix this particular kind of issue, not the other problems th=
at come from order of evaluation issues.<br><br>3) Change the rules of eval=
uation so that users can know that what they&#39;ve written is actually val=
id C++ code.<br></div></blockquote><div>=C2=A0</div><div>Yes, let&#39;s cha=
nge the rules to more closely match what users expect, but I don&#39;t beli=
eve that expectation exists for function arguments specifically; that is, &=
quot;everyone knows&quot; that function arguments are evaluated in indeterm=
inate order. This feels intuitive because (as with, say, addition) the synt=
ax does not imply any dependency between arguments separated by a syntactic=
 comma.</div><div><br></div><div>Note that I&#39;m fine with sequencing the=
 postfix-expression result and object parameter (if any) before the argumen=
ts proper. Doing so would fix the &quot;chaining&quot; example without impa=
cting Kazutoshi&#39;s motivating example.<br></div><div><br></div><div><div=
>Also, if overloaded operators are evaluated according to the corresponding=
 built-in operator (rather than as a function call) then that removes a maj=
or motivation for changing the rules for function calls.</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_2059_804816051.1448018172772--
------=_Part_2058_1668495052.1448018172772--

.

------=_Part_507_2139824262.1448028029127
Content-Type: multipart/alternative;
 boundary="----=_Part_508_546774777.1448028029128"

------=_Part_508_546774777.1448028029128
Content-Type: text/plain; charset=UTF-8



On Friday, November 20, 2015 at 6:16:13 AM UTC-5, Edward Catmur wrote:
>
> On Thursday, 19 November 2015 23:52:54 UTC, Nicol Bolas wrote:
>>
>> Here's the problem. We have three choices:
>>
>> 1) The status quo. That is, we encourage the writing of such code (having
>> functions that return references to `this` encourages it) while
>> simultaneously making it very difficult for a user to know that they've
>> written something incorrect relative to the standard. At best, we can hope
>> for static analysis tools to step in and say "Hey, you did something
>> possibly wrong here." At worse, users write subtle bugs into their programs
>> that only appear on platforms that happen to use a different evaluation
>> order.
>>
>> 2) Change std::string and various other modifiable types so that they're
>> non-modifiable, thus breaking tons of perfectly valid (and reasonably
>> performing) code that has already been written. Note that it will only fix
>> this particular kind of issue, not the other problems that come from order
>> of evaluation issues.
>>
>> 3) Change the rules of evaluation so that users can know that what
>> they've written is actually valid C++ code.
>>
>
> Yes, let's change the rules to more closely match what users expect, but I
> don't believe that expectation exists for function arguments specifically;
> that is, "everyone knows" that function arguments are evaluated in
> indeterminate order. This feels intuitive because (as with, say, addition)
> the syntax does not imply any dependency between arguments separated by a
> syntactic comma.
>

You say that "everyone knows", and yet people still write code that shows
that they don't. "Everyone knows" to destroy objects they allocate, but
people still write code where that doesn't happen. We standardized smart
pointers to make it easier for people to avoid that.

The same goes here. Regardless of what "everyone knows", we can actually
fix it so that their code is reliable.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_508_546774777.1448028029128
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, November 20, 2015 at 6:16:13 AM UTC-5, Edward Catmur wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, 19 November 20=
15 23:52:54 UTC, 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>Here&#39;s the problem. We have three choices:<br><br>1) The status q=
uo. That is, we encourage the writing of such code (having functions that r=
eturn references to `this` encourages it) while simultaneously making it ve=
ry difficult for a user to know that they&#39;ve written something incorrec=
t relative to the standard. At best, we can hope for static analysis tools =
to step in and say &quot;Hey, you did something possibly wrong here.&quot; =
At worse, users write subtle bugs into their programs that only appear on p=
latforms that happen to use a different evaluation order.<br><br>2) Change =
std::string and various other modifiable types so that they&#39;re non-modi=
fiable, thus breaking tons of perfectly valid (and reasonably performing) c=
ode that has already been written. Note that it will only fix this particul=
ar kind of issue, not the other problems that come from order of evaluation=
 issues.<br><br>3) Change the rules of evaluation so that users can know th=
at what they&#39;ve written is actually valid C++ code.<br></div></blockquo=
te><div>=C2=A0</div><div>Yes, let&#39;s change the rules to more closely ma=
tch what users expect, but I don&#39;t believe that expectation exists for =
function arguments specifically; that is, &quot;everyone knows&quot; that f=
unction arguments are evaluated in indeterminate order. This feels intuitiv=
e because (as with, say, addition) the syntax does not imply any dependency=
 between arguments separated by a syntactic comma.</div></blockquote><div><=
br>You say that &quot;everyone knows&quot;, and yet people still write code=
 that shows that they don&#39;t. &quot;Everyone knows&quot; to destroy obje=
cts they allocate, but people still write code where that doesn&#39;t happe=
n. We standardized smart pointers to make it easier for people to avoid tha=
t.<br><br>The same goes here. Regardless of what &quot;everyone knows&quot;=
, we can actually fix it so that their code is reliable.</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_508_546774777.1448028029128--
------=_Part_507_2139824262.1448028029127--

.

On 2015-11-19 23:59, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals wrote:
> On Thu, Nov 19, 2015 at 2:40 PM, Zhihao Yuan <zy@miator.net
> <mailto:zy@miator.net>> wrote:
>
>     For this particular case, I personally don't think that we have to
>     make it work.  In many languages, it works because the string
>     is immutable and `.replace` is creating new objects.  IMHO,
>     referring a mutated object more than once in a sequence of
>     operations in a statement is a bad idea in general, not just in
>     C++.
>
>
> I think this is what bothers me most. That we'd be potentially
> preventing certain optimizations is one thing, but separate from that is
> that by defining the code and its ordering, we'd be effectively
> /sanctioning/ the dependence on it by users. This is at least a little
> bit scary. We'd be changing incorrect code to "correct" but subtle code
> (of course, the fact that it is currently invalid is also sometimes subtle).
>
> I don't have a strong opinion either way, but I do agree that this is an
> important point that shouldn't be overlooked.
>

If the compiler is smart enough, there doesn't have to be any
performance difference from this. If the parameters are independent,
like they have to be now, the compiler can still reorder the evaluation
the way it has always done.

It must just produce a result "as-if" it had evaluated the parameters in
order.


 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/.

.

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

On Fri, Nov 20, 2015 at 2:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Friday, November 20, 2015 at 6:16:13 AM UTC-5, Edward Catmur wrote:
>>
>> On Thursday, 19 November 2015 23:52:54 UTC, Nicol Bolas wrote:
>>>
>>> Here's the problem. We have three choices:
>>>
>>> 1) The status quo. That is, we encourage the writing of such code
>>> (having functions that return references to `this` encourages it) while
>>> simultaneously making it very difficult for a user to know that they've
>>> written something incorrect relative to the standard. At best, we can hope
>>> for static analysis tools to step in and say "Hey, you did something
>>> possibly wrong here." At worse, users write subtle bugs into their programs
>>> that only appear on platforms that happen to use a different evaluation
>>> order.
>>>
>>> 2) Change std::string and various other modifiable types so that they're
>>> non-modifiable, thus breaking tons of perfectly valid (and reasonably
>>> performing) code that has already been written. Note that it will only fix
>>> this particular kind of issue, not the other problems that come from order
>>> of evaluation issues.
>>>
>>> 3) Change the rules of evaluation so that users can know that what
>>> they've written is actually valid C++ code.
>>>
>>
>> Yes, let's change the rules to more closely match what users expect, but
>> I don't believe that expectation exists for function arguments
>> specifically; that is, "everyone knows" that function arguments are
>> evaluated in indeterminate order. This feels intuitive because (as with,
>> say, addition) the syntax does not imply any dependency between arguments
>> separated by a syntactic comma.
>>
>
> You say that "everyone knows", and yet people still write code that shows
> that they don't. "Everyone knows" to destroy objects they allocate, but
> people still write code where that doesn't happen. We standardized smart
> pointers to make it easier for people to avoid that.
>
> The same goes here. Regardless of what "everyone knows", we can actually
> fix it so that their code is reliable.
>

There's a big difference between adding facilities to the library and
narrowing the semantics of the language itself. When users were making
mistakes in memory allocation, the solution was to add smart pointers that
can replace raw pointers as desired; it wasn't to make the language GCd.

You say that people are writing code that depends on function argument
evaluation; how common is this problem? Does it occur frequently enough to
justify the performance impact?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/.

--001a11c3db70403f8005250048d1
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, Nov 20, 2015 at 2:00 PM, 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"><span class=3D""><br><br>On F=
riday, November 20, 2015 at 6:16:13 AM UTC-5, Edward Catmur wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Thursday, 19 November 2015 23:52:54 UTC, =
Nicol Bolas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Here&#39;s =
the problem. We have three choices:<br><br>1) The status quo. That is, we e=
ncourage the writing of such code (having functions that return references =
to `this` encourages it) while simultaneously making it very difficult for =
a user to know that they&#39;ve written something incorrect relative to the=
 standard. At best, we can hope for static analysis tools to step in and sa=
y &quot;Hey, you did something possibly wrong here.&quot; At worse, users w=
rite subtle bugs into their programs that only appear on platforms that hap=
pen to use a different evaluation order.<br><br>2) Change std::string and v=
arious other modifiable types so that they&#39;re non-modifiable, thus brea=
king tons of perfectly valid (and reasonably performing) code that has alre=
ady been written. Note that it will only fix this particular kind of issue,=
 not the other problems that come from order of evaluation issues.<br><br>3=
) Change the rules of evaluation so that users can know that what they&#39;=
ve written is actually valid C++ code.<br></div></blockquote><div>=C2=A0</d=
iv><div>Yes, let&#39;s change the rules to more closely match what users ex=
pect, but I don&#39;t believe that expectation exists for function argument=
s specifically; that is, &quot;everyone knows&quot; that function arguments=
 are evaluated in indeterminate order. This feels intuitive because (as wit=
h, say, addition) the syntax does not imply any dependency between argument=
s separated by a syntactic comma.</div></blockquote></span><div><br>You say=
 that &quot;everyone knows&quot;, and yet people still write code that show=
s that they don&#39;t. &quot;Everyone knows&quot; to destroy objects they a=
llocate, but people still write code where that doesn&#39;t happen. We stan=
dardized smart pointers to make it easier for people to avoid that.<br><br>=
The same goes here. Regardless of what &quot;everyone knows&quot;, we can a=
ctually fix it so that their code is reliable.</div></blockquote><div><br><=
/div><div>There&#39;s a big difference between adding facilities to the lib=
rary and narrowing the semantics of the language itself. When users were ma=
king mistakes in memory allocation, the solution was to add smart pointers =
that can replace raw pointers as desired; it wasn&#39;t to make the languag=
e GCd.</div><div><br></div><div>You say that people are writing code that d=
epends on function argument evaluation; how common is this problem? Does it=
 occur frequently enough to justify the performance impact?</div></div></di=
v></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 />

--001a11c3db70403f8005250048d1--

.

------=_Part_3509_2122831654.1448059731001
Content-Type: multipart/alternative;
 boundary="----=_Part_3510_199506363.1448059731001"

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

On Thursday, November 19, 2015 at 3:52:54 PM UTC-8, Nicol Bolas wrote:
>
> On Thursday, November 19, 2015 at 5:59:07 PM UTC-5, Matt Calabrese wrote:
>>
>> On Thu, Nov 19, 2015 at 2:40 PM, Zhihao Yuan <z...@miator.net> wrote:
>>>
>>> For this particular case, I personally don't think that we have to
>>> make it work.
>>
>>
I would agree that the "motivating example" in the paper (taken from=20
Bjarne's book) is really a terrible example, because OF COURSE no=20
reasonable programmer would write a line of code so convoluted and expect=
=20
it to work =E2=80=94 and when it didn't work, any maintainer's first reacti=
on would=20
be to split up the convoluted expression into several statements, at which=
=20
point the bug would go away.
However, there are plenty more motivating examples.

There's the motivating example for std::make_unique =E2=80=94

    void capture_as_uniqueptrs(std::unique_ptr<A>, std::unique_ptr<B>);

    int main() { capture_as_uniqueptrs(new A, new B); }

If "new A" and "new B" are unsequenced relative to each other, then the=20
order of evaluation "allocate A - allocate B - construct A - construct B"=
=20
is possible, and if A's constructor throws, B's memory leaks. If function=
=20
argument evaluations are sequenced, then this problem goes away, I think.

There's a very wrong but very common "mis-pattern" in parsing code =E2=80=
=94

    int scan_function_decl(FILE *in) {  // returns bytes consumed from the=
=20
stream
        return scan_return_type(in) + scan_identifier(in) +=20
scan_parameter_list(in);
    }

As I understand it, this code would NOT be fixed by P0145.
=20

I think this is what bothers me most. That we'd be potentially preventing=
=20
>> certain optimizations is one thing, but separate from that is that by=20
>> defining the code and its ordering, we'd be effectively *sanctioning*=20
>> the dependence on it by users. This is at least a little bit scary. We'd=
 be=20
>> changing incorrect code to "correct" but subtle code (of course, the fac=
t=20
>> that it is currently invalid is also sometimes subtle).
>>
>> I don't have a strong opinion either way, but I do agree that this is an=
=20
>> important point that shouldn't be overlooked.
>>
>
> Here's the problem. We have three choices:
>
> 1) The status quo. That is, we encourage the writing of such code (having=
=20
> functions that return references to `this` encourages it) while=20
> simultaneously making it very difficult for a user to know that they've=
=20
> written something incorrect relative to the standard. At best, we can hop=
e=20
> for static analysis tools to step in and say "Hey, you did something=20
> possibly wrong here." At worse, users write subtle bugs into their progra=
ms=20
> that only appear on platforms that happen to use a different evaluation=
=20
> order.
>

Don't forget the most relevant aspect of the status quo =E2=80=94 New langu=
age=20
features tend to be explicitly defined to evaluate things in left-to-right=
=20
order. :P  At least that's been true of braced initializer-lists (including=
=20
the way they interact with parameter-packs).  So we've got "New C++"=20
features that tend to well-define evaluation order, mixed in with "Old C++"=
=20
(a.k.a. "C") features that tend to leave it undefined. This is a bad state=
=20
to be in, because the user has to constantly remember which kind of=20
construct he's using at the moment. It also leads to stupid template tricks=
=20
such as

    std::tuple<decay_t<decltype(F(A))>...> t { F(A)... };
    // can't use `auto t =3D std::make_tuple(F(A)...);` because it doesn't=
=20
evaluate the operands in the order I want them

As I understand it, P0145 would fix a lot of this problem (but not all of=
=20
it).

Tangent: My own pet peeve about P0145R0 is that it provides a defined OOE=
=20
for operator<< and operator>> "because iostreams", but fails to define the=
=20
OOE of most other operators. So it fails to fix the operator+ example=20
above, and it also misses the opportunity to define OOE for operator|=20
"because ranges" or operator/ "because filesystem" or any other=20
soon-to-be-common chaining cases that I might have missed. I'd like to see=
=20
P0145 either undefine OOE for << >> (i.e., let's please not use iostreams=
=20
as a rationale for anything ever), or define OOE for all operators (i.e.,=
=20
let's remove a whole category of questions from Stack Overflow in one fell=
=20
swoop).

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

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

<div dir=3D"ltr">On Thursday, November 19, 2015 at 3:52:54 PM UTC-8, Nicol =
Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, Novem=
ber 19, 2015 at 5:59:07 PM UTC-5, Matt Calabrese wrote:<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><div class=3D"gmail_quote">On Thu=
, Nov 19, 2015 at 2:40 PM, Zhihao Yuan <span dir=3D"ltr">&lt;<a rel=3D"nofo=
llow">z...@miator.net</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">F=
or this particular case, I personally don&#39;t think that we have to<br>
make it work.</blockquote></div></div></div></blockquote></blockquote><div>=
<br></div><div>I would agree that the &quot;motivating example&quot; in the=
 paper (taken from Bjarne&#39;s book) is really a terrible example, because=
 OF COURSE no reasonable programmer would write a line of code so convolute=
d and expect it to work =E2=80=94 and when it didn&#39;t work, any maintain=
er&#39;s first reaction would be to split up the convoluted expression into=
 several statements, at which point the bug would go away.</div><div>Howeve=
r, there are plenty more motivating examples.</div><div><br></div><div>Ther=
e&#39;s the motivating example for std::make_unique =E2=80=94</div><div><br=
></div><div>=C2=A0 =C2=A0 void capture_as_uniqueptrs(std::unique_ptr&lt;A&g=
t;, std::unique_ptr&lt;B&gt;);</div><div><br></div><div>=C2=A0 =C2=A0 int m=
ain() { capture_as_uniqueptrs(new A, new B); }</div><div><br></div><div>If =
&quot;new A&quot; and &quot;new B&quot; are unsequenced relative to each ot=
her, then the order of evaluation &quot;allocate A - allocate B - construct=
 A - construct B&quot; is possible, and if A&#39;s constructor throws, B&#3=
9;s memory leaks. If function argument evaluations are sequenced, then this=
 problem goes away, I think.</div><div><br></div><div>There&#39;s a very wr=
ong but very common &quot;mis-pattern&quot; in parsing code =E2=80=94</div>=
<div><br></div><div>=C2=A0 =C2=A0 int scan_function_decl(FILE *in) { =C2=A0=
// returns bytes consumed from the stream</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return scan_return_type(in) + scan_identifier(in) + scan_parameter_l=
ist(in);</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>As I understand=
 it, this code would NOT be fixed by P0145.</div><div>=C2=A0<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;"><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 class=3D"gmail_quote"><div>I thin=
k this is what bothers me most. That we&#39;d be potentially preventing cer=
tain optimizations is one thing, but separate from that is that by defining=
 the code and its ordering, we&#39;d be effectively <i>sanctioning</i> the =
dependence on it by users. This is at least a little bit scary. We&#39;d be=
 changing incorrect code to &quot;correct&quot; but subtle code (of course,=
 the fact that it is currently invalid is also sometimes subtle).<br></div>=
<div><br></div><div>I don&#39;t have a strong opinion either way, but I do =
agree that this is an important point that shouldn&#39;t be overlooked.</di=
v></div></div></blockquote><div><br>Here&#39;s the problem. We have three c=
hoices:<br><br>1) The status quo. That is, we encourage the writing of such=
 code (having functions that return references to `this` encourages it) whi=
le simultaneously making it very difficult for a user to know that they&#39=
;ve written something incorrect relative to the standard. At best, we can h=
ope for static analysis tools to step in and say &quot;Hey, you did somethi=
ng possibly wrong here.&quot; At worse, users write subtle bugs into their =
programs that only appear on platforms that happen to use a different evalu=
ation order.<br></div></blockquote><div><br></div><div>Don&#39;t forget the=
 most relevant aspect of the status quo =E2=80=94 New language features ten=
d to be explicitly defined to evaluate things in left-to-right order. :P =
=C2=A0At least that&#39;s been true of braced initializer-lists (including =
the way they interact with parameter-packs). =C2=A0So we&#39;ve got &quot;N=
ew C++&quot; features that tend to well-define evaluation order, mixed in w=
ith &quot;Old C++&quot; (a.k.a. &quot;C&quot;) features that tend to leave =
it undefined. This is a bad state to be in, because the user has to constan=
tly remember which kind of construct he&#39;s using at the moment. It also =
leads to stupid template tricks such as</div><div><br></div><div>=C2=A0 =C2=
=A0 std::tuple&lt;decay_t&lt;decltype(F(A))&gt;...&gt; t { F(A)... };</div>=
<div>=C2=A0 =C2=A0 // can&#39;t use `auto t =3D std::make_tuple(F(A)...);` =
because it doesn&#39;t evaluate the operands in the order I want them</div>=
<div><br></div><div>As I understand it, P0145 would fix a lot of this probl=
em (but not all of it).</div><div><br></div><div>Tangent: My own pet peeve =
about P0145R0 is that it provides a defined OOE for operator&lt;&lt; and op=
erator&gt;&gt; &quot;because iostreams&quot;, but fails to define the OOE o=
f most other operators. So it fails to fix the operator+ example above, and=
 it also misses the opportunity to define OOE for operator| &quot;because r=
anges&quot; or operator/ &quot;because filesystem&quot; or any other soon-t=
o-be-common chaining cases that I might have missed. I&#39;d like to see P0=
145 either undefine OOE for &lt;&lt; &gt;&gt; (i.e., let&#39;s please not u=
se iostreams as a rationale for anything ever), or define OOE for all opera=
tors (i.e., let&#39;s remove a whole category of questions from Stack Overf=
low in one fell swoop).</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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3510_199506363.1448059731001--
------=_Part_3509_2122831654.1448059731001--

.

------=_Part_2526_1426372179.1448107234324
Content-Type: multipart/alternative;
 boundary="----=_Part_2527_280079347.1448107234324"

------=_Part_2527_280079347.1448107234324
Content-Type: text/plain; charset=UTF-8

On Saturday, November 21, 2015 at 12:48:51 AM UTC+2, Arthur O'Dwyer wrote:
>
> So it fails to fix the operator+ example above, and it also misses the
> opportunity to define OOE for operator| "because ranges" or operator/
> "because filesystem" or any other soon-to-be-common chaining cases that I
> might have missed.
>

If only they left out this rule from P0145:

- Furthermore, we suggest the following additional rule: the order of
evaluation of an expression involving an overloaded operator is determined
by the order associated with the corresponding built-in operator, not the
rules for function calls. This rule is to support generic programming and
extensive use of overloaded operators, which are distinctive features of
modern C++.

Without this rule, the order of evaluation for all overloaded operators
would have been 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_2527_280079347.1448107234324
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, November 21, 2015 at 12:48:51 AM UTC+2, Arthu=
r O&#39;Dwyer wrote:<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"ltr">So it fails to fix the operator+ example above, and it also misses=
 the opportunity to define OOE for operator| &quot;because ranges&quot; or =
operator/ &quot;because filesystem&quot; or any other soon-to-be-common cha=
ining cases that I might have missed.</div></blockquote><div><br></div><div=
>If only they left out this rule from P0145:</div><div><br></div><div>- Fur=
thermore, we suggest the following additional rule: the order of evaluation=
 of an expression involving an overloaded operator is determined by the ord=
er associated with the corresponding built-in operator, not the rules for f=
unction calls. This rule is to support generic programming and extensive us=
e of overloaded operators, which are distinctive features of modern C++.=C2=
=A0</div><div><br></div><div>Without this rule, the order of evaluation for=
 all overloaded operators would have been specified.</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_2527_280079347.1448107234324--
------=_Part_2526_1426372179.1448107234324--

.

------=_Part_204_1180178736.1448113897342
Content-Type: multipart/alternative;
 boundary="----=_Part_205_1551937997.1448113897342"

------=_Part_205_1551937997.1448113897342
Content-Type: text/plain; charset=UTF-8



On Saturday, November 21, 2015 at 7:00:34 AM UTC-5, wher...@gmail.com wrote:
>
> On Saturday, November 21, 2015 at 12:48:51 AM UTC+2, Arthur O'Dwyer wrote:
>>
>> So it fails to fix the operator+ example above, and it also misses the
>> opportunity to define OOE for operator| "because ranges" or operator/
>> "because filesystem" or any other soon-to-be-common chaining cases that I
>> might have missed.
>>
>
> If only they left out this rule from P0145:
>
> - Furthermore, we suggest the following additional rule: the order of
> evaluation of an expression involving an overloaded operator is determined
> by the order associated with the corresponding built-in operator, not the
> rules for function calls. This rule is to support generic programming and
> extensive use of overloaded operators, which are distinctive features of
> modern C++.
>
> Without this rule, the order of evaluation for all overloaded operators
> would have been specified.
>

Wait, I'm confused.

First, there does not appear to be any special case wording in P0145
"because iostreams". From a cursory glance at P0145, particularly the
quoted section above, it seems that they do define the order of evaluation
for overloaded operators.

Where is OOE undefined for overloaded operators? Chaining seems to be one
of the key motivations behind P0145; where did they miss a case that makes
evaluation order not defined?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_205_1551937997.1448113897342
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Saturday, November 21, 2015 at 7:00:34 AM UTC-5, wher...@gmail.c=
om 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 S=
aturday, November 21, 2015 at 12:48:51 AM UTC+2, Arthur O&#39;Dwyer 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">So it fails to fix =
the operator+ example above, and it also misses the opportunity to define O=
OE for operator| &quot;because ranges&quot; or operator/ &quot;because file=
system&quot; or any other soon-to-be-common chaining cases that I might hav=
e missed.</div></blockquote><div><br></div><div>If only they left out this =
rule from P0145:</div><div><br></div><div>- Furthermore, we suggest the fol=
lowing additional rule: the order of evaluation of an expression involving =
an overloaded operator is determined by the order associated with the corre=
sponding built-in operator, not the rules for function calls. This rule is =
to support generic programming and extensive use of overloaded operators, w=
hich are distinctive features of modern C++.=C2=A0</div><div><br></div><div=
>Without this rule, the order of evaluation for all overloaded operators wo=
uld have been specified.</div></div></blockquote><div><br>Wait, I&#39;m con=
fused.<br><br>First, there does not appear to be any special case wording i=
n P0145 &quot;because iostreams&quot;. From a cursory glance at P0145, part=
icularly the quoted section above, it seems that they do define the order o=
f evaluation for overloaded operators.<br><br>Where is OOE undefined for ov=
erloaded operators? Chaining seems to be one of the key motivations behind =
P0145; where did they miss a case that makes evaluation order not defined?<=
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_205_1551937997.1448113897342--
------=_Part_204_1180178736.1448113897342--

.

------=_Part_3263_2128761342.1448114302630
Content-Type: multipart/alternative;
 boundary="----=_Part_3264_171569319.1448114302630"

------=_Part_3264_171569319.1448114302630
Content-Type: text/plain; charset=UTF-8

On Saturday, November 21, 2015 at 8:51:37 AM UTC-5, Nicol Bolas wrote:
>
> On Saturday, November 21, 2015 at 7:00:34 AM UTC-5, wher...@gmail.com
> wrote:
>>
>> On Saturday, November 21, 2015 at 12:48:51 AM UTC+2, Arthur O'Dwyer wrote:
>>>
>>> So it fails to fix the operator+ example above, and it also misses the
>>> opportunity to define OOE for operator| "because ranges" or operator/
>>> "because filesystem" or any other soon-to-be-common chaining cases that I
>>> might have missed.
>>>
>>
>> If only they left out this rule from P0145:
>>
>> - Furthermore, we suggest the following additional rule: the order of
>> evaluation of an expression involving an overloaded operator is determined
>> by the order associated with the corresponding built-in operator, not the
>> rules for function calls. This rule is to support generic programming and
>> extensive use of overloaded operators, which are distinctive features of
>> modern C++.
>>
>> Without this rule, the order of evaluation for all overloaded operators
>> would have been specified.
>>
>
> Wait, I'm confused.
>
> First, there does not appear to be any special case wording in P0145
> "because iostreams". From a cursory glance at P0145, particularly the
> quoted section above, it seems that they do define the order of evaluation
> for overloaded operators.
>
> Where is OOE undefined for overloaded operators? Chaining seems to be one
> of the key motivations behind P0145; where did they miss a case that makes
> evaluation order not defined?
>

Actually, never mind, I see it now. Though they have a good point about
reducing the scale of it ("politics is the art of the possible", after all).

I still disagree that the above section is problematic. It's perfectly
reasonable for overloaded operators to be sequenced in the order of the
standard ones.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_3264_171569319.1448114302630
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, November 21, 2015 at 8:51:37 AM UTC-5, Nicol Bolas 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 Saturday, November 21, 2015 at 7=
:00:34 AM UTC-5, <a>wher...@gmail.com</a> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">On Saturday, November 21, 2015 at 12:48:51 AM=
 UTC+2, Arthur O&#39;Dwyer 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">So it fails to fix the operator+ example above, and it also =
misses the opportunity to define OOE for operator| &quot;because ranges&quo=
t; or operator/ &quot;because filesystem&quot; or any other soon-to-be-comm=
on chaining cases that I might have missed.</div></blockquote><div><br></di=
v><div>If only they left out this rule from P0145:</div><div><br></div><div=
>- Furthermore, we suggest the following additional rule: the order of eval=
uation of an expression involving an overloaded operator is determined by t=
he order associated with the corresponding built-in operator, not the rules=
 for function calls. This rule is to support generic programming and extens=
ive use of overloaded operators, which are distinctive features of modern C=
++.=C2=A0</div><div><br></div><div>Without this rule, the order of evaluati=
on for all overloaded operators would have been specified.</div></div></blo=
ckquote><div><br>Wait, I&#39;m confused.<br><br>First, there does not appea=
r to be any special case wording in P0145 &quot;because iostreams&quot;. Fr=
om a cursory glance at P0145, particularly the quoted section above, it see=
ms that they do define the order of evaluation for overloaded operators.<br=
><br>Where is OOE undefined for overloaded operators? Chaining seems to be =
one of the key motivations behind P0145; where did they miss a case that ma=
kes evaluation order not defined?<br></div></blockquote><div><br>Actually, =
never mind, I see it now. Though they have a good point about reducing the =
scale of it (&quot;politics is the art of the possible&quot;, after all).<b=
r><br>I still disagree that the above section is problematic. It&#39;s perf=
ectly reasonable for overloaded operators to be sequenced in the order of t=
he standard ones.<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_3264_171569319.1448114302630--
------=_Part_3263_2128761342.1448114302630--

.

On 2015/11/20 6:19 +0900, Gabriel Dos Reis wrote:
> Note that the issue isn't that there won't be difference in codegen
> (that actually is the whole point of the proposal.)  The question is
> whether any  additional overhead is measurable in typical scenario and
> if so whether it is tolerable compared to alternatives (the traps we
> have today.)

Do you have any reasonings (from your experiences?) to presume the
pattern (shown in OP) is not typical, or not measurable, or the overhead
is tolerable?

For example, I think it's OK to add a sequence rule between evaluations
of function and its arguments, because it's not typical, in my
experience, to have complex subexpressions on function parts.

> I expect compilers to also offer switches for non-standard evaluation
> order, just like some have -funsafe-math.

I doubt the usefulness of such switches.

Once the order is specified and people have been allowed to write codes
depending on that order, use of such compiler switches can result in
completely different behavior with far higher possibility than
-funsafe-math. AFAIK, the effect of -funsafe-math is often limited to
the accuracy of floating arithmetics, which is implementation-defined in
the first place.

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

.

On 2015/11/20 5:24 +0900, Kazutoshi Satoda wrote:
> I found only the following about performance concern of P0145R0:
> https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report
>>   Performance was a concern: will performance suffer? It will for some
>>   older machine architectures (1% was mentioned), but there can be
>>   backwards compatibility switches and performance-sensitive
>>   applications have mostly moved to architectures where there is no
>>   performance degradation years ago.
>>
>>   This proposal was accepted.
> But I think the above mentioned prohibition of transformation is general
> issue, not only on older machine architectures, and can be noticeable
> performance difference.
>
> Is these kind of concern already discussed?

Now I found another trip report with a comment which includes what has
been mentioned as the performance impact of P0145R0.
https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/#comment-219
> One example that came up during the EWG discussion was that different
> platform ABIs require pushing function arguments onto the stack in
> different orders, and it decreases register pressure to evaluate the
> arguments in the order that they will be pushed.
Then it is understandable that the impact was estimated as "1%" "for
some older machine architectures".

It seems that this kind of concern has not been considered as a
consequence of P0145R0 so far.

My concern can be said as a reduction of possibility of "common
subexpression elimination (CSE)"
<https://en.wikipedia.org/wiki/Common_subexpression_elimination>.
The impact may increase in the future as compilers become wiser.

I want EWG reconsider P0145R0 with this concern in mind, and hopefully
drop at least the part of function arguments from the proposal.

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

.

On 2015/11/21 1:45 +0900, Bo Persson wrote:
> If the compiler is smart enough, there doesn't have to be any
> performance difference from this. If the parameters are independent,
> like they have to be now, the compiler can still reorder the evaluation
> the way it has always done.

The difference is, "the parameters are independent" can be assumed (now)
or must be proven (P0145R0). And it can't be proven if a (sub)expression
contains a call to unknown function via a pointer or virtual call.

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

.

------=_Part_1441_1115146499.1448163479408
Content-Type: multipart/alternative;
 boundary="----=_Part_1442_407804368.1448163479409"

------=_Part_1442_407804368.1448163479409
Content-Type: text/plain; charset=UTF-8

On Saturday, November 21, 2015 at 3:55:51 PM UTC-5, Kazutoshi SATODA wrote:
>
> On 2015/11/20 6:19 +0900, Gabriel Dos Reis wrote:
> > Note that the issue isn't that there won't be difference in codegen
> > (that actually is the whole point of the proposal.)  The question is
> > whether any  additional overhead is measurable in typical scenario and
> > if so whether it is tolerable compared to alternatives (the traps we
> > have today.)
>
> Do you have any reasonings (from your experiences?) to presume the
> pattern (shown in OP) is not typical, or not measurable, or the overhead
> is tolerable?
>
> For example, I think it's OK to add a sequence rule between evaluations
> of function and its arguments, because it's not typical, in my
> experience, to have complex subexpressions on function parts.
>
> > I expect compilers to also offer switches for non-standard evaluation
> > order, just like some have -funsafe-math.
>
> I doubt the usefulness of such switches.
>
> Once the order is specified and people have been allowed to write codes
> depending on that order, use of such compiler switches can result in
> completely different behavior with far higher possibility than
> -funsafe-math. AFAIK, the effect of -funsafe-math is often limited to
> the accuracy of floating arithmetics, which is implementation-defined in
> the first place.
>

What is the difference between this switch and the switch to turn off
strict aliasing? Strict aliasing and, let's call it, strict ordering both
are intended to improve safety by keeping the compiler from doing something
that's probably unsafe. And yet, you have adherents to swear that strict
aliasing kills valid compiler optimizations. Just as you believe that
strict ordering kills valid compiler optimizations.

So what is the difference?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_1442_407804368.1448163479409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, November 21, 2015 at 3:55:51 PM UTC-5, Kazutoshi SATODA 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/11/20 6:19 +0900, Gabr=
iel Dos Reis wrote:
<br>&gt; Note that the issue isn&#39;t that there won&#39;t be difference i=
n codegen
<br>&gt; (that actually is the whole point of the proposal.) =C2=A0The ques=
tion is
<br>&gt; whether any =C2=A0additional overhead is measurable in typical sce=
nario and
<br>&gt; if so whether it is tolerable compared to alternatives (the traps =
we
<br>&gt; have today.)
<br>
<br>Do you have any reasonings (from your experiences?) to presume the
<br>pattern (shown in OP) is not typical, or not measurable, or the overhea=
d
<br>is tolerable?
<br>
<br>For example, I think it&#39;s OK to add a sequence rule between evaluat=
ions
<br>of function and its arguments, because it&#39;s not typical, in my
<br>experience, to have complex subexpressions on function parts.
<br>
<br>&gt; I expect compilers to also offer switches for non-standard evaluat=
ion
<br>&gt; order, just like some have -funsafe-math.
<br>
<br>I doubt the usefulness of such switches.
<br>
<br>Once the order is specified and people have been allowed to write codes
<br>depending on that order, use of such compiler switches can result in
<br>completely different behavior with far higher possibility than
<br>-funsafe-math. AFAIK, the effect of -funsafe-math is often limited to
<br>the accuracy of floating arithmetics, which is implementation-defined i=
n
<br>the first place.
<br></blockquote><div><br>What is the difference between this switch and th=
e switch to turn off strict aliasing? Strict aliasing and, let&#39;s call i=
t, strict ordering both are intended to improve safety by keeping the compi=
ler from doing something that&#39;s probably unsafe. And yet, you have adhe=
rents to swear that strict aliasing kills valid compiler optimizations. Jus=
t as you believe that strict ordering kills valid compiler optimizations.<b=
r><br>So what is the difference?<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_1442_407804368.1448163479409--
------=_Part_1441_1115146499.1448163479408--

.

------=_Part_2335_29431129.1448164429237
Content-Type: multipart/alternative;
 boundary="----=_Part_2336_1189186139.1448164429237"

------=_Part_2336_1189186139.1448164429237
Content-Type: text/plain; charset=UTF-8

On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazutoshi SATODA wrote:
>
> On 2015/11/20 5:24 +0900, Kazutoshi Satoda wrote:
> > I found only the following about performance concern of P0145R0:
> > https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report
> >>   Performance was a concern: will performance suffer? It will for some
> >>   older machine architectures (1% was mentioned), but there can be
> >>   backwards compatibility switches and performance-sensitive
> >>   applications have mostly moved to architectures where there is no
> >>   performance degradation years ago.
> >>
> >>   This proposal was accepted.
> > But I think the above mentioned prohibition of transformation is general
> > issue, not only on older machine architectures, and can be noticeable
> > performance difference.
> >
> > Is these kind of concern already discussed?
>
> Now I found another trip report with a comment which includes what has
> been mentioned as the performance impact of P0145R0.
>
> https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/#comment-219
> > One example that came up during the EWG discussion was that different
> > platform ABIs require pushing function arguments onto the stack in
> > different orders, and it decreases register pressure to evaluate the
> > arguments in the order that they will be pushed.
> Then it is understandable that the impact was estimated as "1%" "for
> some older machine architectures".
>
> It seems that this kind of concern has not been considered as a
> consequence of P0145R0 so far.
>

So you see one comment on a trip report, and immediately assume that this
was the totality of the discussion at the meeting? That's a pretty huge
leap to be making.

My concern can be said as a reduction of possibility of "common
> subexpression elimination (CSE)"
> <https://en.wikipedia.org/wiki/Common_subexpression_elimination>.
> The impact may increase in the future as compilers become wiser.
>

If "compilers become wiser" about this, it would only be through knowing
more about what is being compiled. And if compilers know more about what is
being compiled, they will be better able to know when code is not
order-dependent.

Indeed, the smarter the compiler gets, the more it knows about the code,
the *lower* the chance of needing to rely on non-strict ordering to get
appropriate optimizations. After all, if your code is not order-dependent,
and the compiler knows it, then there's no problem; the compiler can
reorder things because you can't tell the difference. The problem only
happens when your code is not order-dependent, but the compiler can only
guess that it is.

Personally, I'd prefer that my compiler not break my code while trying to
optimize it. And if my compiler doesn't *know* that it's safe to re-order
various expressions for parameters and such, then it shouldn't.

--

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

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

On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazutoshi SATODA 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/11/20 5:24 +0900, Kazu=
toshi Satoda wrote:
<br>&gt; I found only the following about performance concern of P0145R0:
<br>&gt; <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\75https%3A%2F%2Fisocpp.org%2Fblog%2F2015%=
2F11%2Fkona-standards-meeting-trip-report\46sa\75D\46sntz\0751\46usg\75AFQj=
CNEqYLuQO11BCv_AYTNRcsyrE0KXnQ&#39;;return true;" onclick=3D"this.href=3D&#=
39;https://www.google.com/url?q\75https%3A%2F%2Fisocpp.org%2Fblog%2F2015%2F=
11%2Fkona-standards-meeting-trip-report\46sa\75D\46sntz\0751\46usg\75AFQjCN=
EqYLuQO11BCv_AYTNRcsyrE0KXnQ&#39;;return true;">https://isocpp.org/blog/201=
5/<wbr>11/kona-standards-meeting-<wbr>trip-report</a>
<br>&gt;&gt; =C2=A0 Performance was a concern: will performance suffer? It =
will for some
<br>&gt;&gt; =C2=A0 older machine architectures (1% was mentioned), but the=
re can be
<br>&gt;&gt; =C2=A0 backwards compatibility switches and performance-sensit=
ive
<br>&gt;&gt; =C2=A0 applications have mostly moved to architectures where t=
here is no
<br>&gt;&gt; =C2=A0 performance degradation years ago.
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 This proposal was accepted.
<br>&gt; But I think the above mentioned prohibition of transformation is g=
eneral
<br>&gt; issue, not only on older machine architectures, and can be noticea=
ble
<br>&gt; performance difference.
<br>&gt;=20
<br>&gt; Is these kind of concern already discussed?
<br>
<br>Now I found another trip report with a comment which includes what has
<br>been mentioned as the performance impact of P0145R0.
<br><a href=3D"https://botondballo.wordpress.com/2015/11/09/trip-report-c-s=
tandards-meeting-in-kona-october-2015/#comment-219" 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%23comment-219\46sa\75D\46sntz\075=
1\46usg\75AFQjCNFpki36p_pBIvYOGfCaiaRZgHxnqw&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fbotondballo.w=
ordpress.com%2F2015%2F11%2F09%2Ftrip-report-c-standards-meeting-in-kona-oct=
ober-2015%2F%23comment-219\46sa\75D\46sntz\0751\46usg\75AFQjCNFpki36p_pBIvY=
OGfCaiaRZgHxnqw&#39;;return true;">https://botondballo.wordpress.<wbr>com/2=
015/11/09/trip-report-c-<wbr>standards-meeting-in-kona-<wbr>october-2015/#c=
omment-219</a>
<br>&gt; One example that came up during the EWG discussion was that differ=
ent
<br>&gt; platform ABIs require pushing function arguments onto the stack in
<br>&gt; different orders, and it decreases register pressure to evaluate t=
he
<br>&gt; arguments in the order that they will be pushed.
<br>Then it is understandable that the impact was estimated as &quot;1%&quo=
t; &quot;for
<br>some older machine architectures&quot;.
<br>
<br>It seems that this kind of concern has not been considered as a
<br>consequence of P0145R0 so far.<br></blockquote><div><br>So you see one =
comment on a trip report, and immediately assume that this was the totality=
 of the discussion at the meeting? That&#39;s a pretty huge leap to be maki=
ng.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
My concern can be said as a reduction of possibility of &quot;common
<br>subexpression elimination (CSE)&quot;
<br>&lt;<a href=3D"https://en.wikipedia.org/wiki/Common_subexpression_elimi=
nation" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FComm=
on_subexpression_elimination\46sa\75D\46sntz\0751\46usg\75AFQjCNEj_kACFHti0=
4yyCXghABmsUJvbvQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://ww=
w.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCommon_subexpr=
ession_elimination\46sa\75D\46sntz\0751\46usg\75AFQjCNEj_kACFHti04yyCXghABm=
sUJvbvQ&#39;;return true;">https://en.wikipedia.org/<wbr>wiki/Common_subexp=
ression_<wbr>elimination</a>&gt;.
<br>The impact may increase in the future as compilers become wiser.<br></b=
lockquote><div><br>If &quot;compilers become wiser&quot; about this, it wou=
ld only be through knowing more about what is being compiled. And if compil=
ers know more about what is being compiled, they will be better able to kno=
w when code is not order-dependent.<br><br>Indeed, the smarter the compiler=
 gets, the more it knows about the code, the <i>lower</i> the chance of nee=
ding to rely on non-strict ordering to get appropriate optimizations. After=
 all, if your code is not order-dependent, and the compiler knows it, then =
there&#39;s no problem; the compiler can reorder things because you can&#39=
;t tell the difference. The problem only happens when your code is not orde=
r-dependent, but the compiler can only guess that it is.<br><br>Personally,=
 I&#39;d prefer that my compiler not break my code while trying to optimize=
 it. And if my compiler doesn&#39;t <i>know</i> that it&#39;s safe to re-or=
der various expressions for parameters and such, then it shouldn&#39;t.<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_2336_1189186139.1448164429237--
------=_Part_2335_29431129.1448164429237--

.

On 2015/11/22 12:37 +0900, Nicol Bolas wrote:
> On Saturday, November 21, 2015 at 3:55:51 PM UTC-5, Kazutoshi SATODA wrote:
>> On 2015/11/20 6:19 +0900, Gabriel Dos Reis wrote:
>>> I expect compilers to also offer switches for non-standard evaluation
>>> order, just like some have -funsafe-math.
>>
>> I doubt the usefulness of such switches.
>>
>> Once the order is specified and people have been allowed to write codes
>> depending on that order, use of such compiler switches can result in
>> completely different behavior with far higher possibility than
>> -funsafe-math. AFAIK, the effect of -funsafe-math is often limited to
>> the accuracy of floating arithmetics, which is implementation-defined in
>> the first place.
>
> What is the difference between this switch and the switch to turn off
> strict aliasing? Strict aliasing and, let's call it, strict ordering both
> are intended to improve safety by keeping the compiler from doing something
> that's probably unsafe. And yet, you have adherents to swear that strict
> aliasing kills valid compiler optimizations. Just as you believe that
> strict ordering kills valid compiler optimizations.
>
> So what is the difference?

Turning off "strict aliasing" will disable some optimization and may
save some non-portable codes. The optimization is standard conforming.

Turning on "strict ordering" ("switches for non-standard evaluation
order") will enable some optimization and may break some "valid"
(depending on the change in P0145R0) codes. The optimization is not
"standard" conforming.

They are clearly different for me.

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

.

On 2015/11/22 12:53 +0900, Nicol Bolas wrote:
> On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazutoshi SATODA wrote:
>> On 2015/11/20 5:24 +0900, Kazutoshi Satoda wrote:
....
>>> Is these kind of concern already discussed?
>>
>> Now I found another trip report with a comment which includes what has
>> been mentioned as the performance impact of P0145R0.
....
>> It seems that this kind of concern has not been considered as a
>> consequence of P0145R0 so far.
>
> So you see one comment on a trip report, and immediately assume that this
> was the totality of the discussion at the meeting? That's a pretty huge
> leap to be making.

I said "it seems" with some supporting circumstance. If you know it
isn't, please let me know. That is the question of my OP, which is not
answered yet.

>> The impact may increase in the future as compilers become wiser.
>
> If "compilers become wiser" about this, it would only be through knowing
> more about what is being compiled. And if compilers know more about what is
> being compiled, they will be better able to know when code is not
> order-dependent.
>
> Indeed, the smarter the compiler gets, the more it knows about the code,
> the *lower* the chance of needing to rely on non-strict ordering to get
> appropriate optimizations. After all, if your code is not order-dependent,
> and the compiler knows it, then there's no problem; the compiler can
> reorder things because you can't tell the difference. The problem only
> happens when your code is not order-dependent, but the compiler can only
> guess that it is.

My earlier reply to Bo Persson seems applicable here:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/IJDqDAamBQAJ
> The difference is, "the parameters are independent" can be assumed (now)
> or must be proven (P0145R0). And it can't be proven if a (sub)expression
> contains a call to unknown function via a pointer or virtual call.

And, AFAIK, compilers in present still can't prove much of independence
between a call to function in different translation unit and a non-local
variable. So GCC has attributes "pure", "const" and they are proposed to
be in the standard.
("The [[pure]] attribute" <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0078r0.pdf>)

Do you have any reasoning to foresee so much improvement of
analyzability in the time frame of C++17 (the target of the proposal)?
I don't.

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

.

------=_Part_4087_711956688.1448200464048
Content-Type: multipart/alternative;
 boundary="----=_Part_4088_1249739287.1448200464048"

------=_Part_4088_1249739287.1448200464048
Content-Type: text/plain; charset=UTF-8

On Sunday, November 22, 2015 at 1:20:53 AM UTC-5, Kazutoshi SATODA wrote:
>
> On 2015/11/22 12:37 +0900, Nicol Bolas wrote:
> > On Saturday, November 21, 2015 at 3:55:51 PM UTC-5, Kazutoshi SATODA
> wrote:
> >> On 2015/11/20 6:19 +0900, Gabriel Dos Reis wrote:
> >>> I expect compilers to also offer switches for non-standard evaluation
> >>> order, just like some have -funsafe-math.
> >>
> >> I doubt the usefulness of such switches.
> >>
> >> Once the order is specified and people have been allowed to write codes
> >> depending on that order, use of such compiler switches can result in
> >> completely different behavior with far higher possibility than
> >> -funsafe-math. AFAIK, the effect of -funsafe-math is often limited to
> >> the accuracy of floating arithmetics, which is implementation-defined
> in
> >> the first place.
> >
> > What is the difference between this switch and the switch to turn off
> > strict aliasing? Strict aliasing and, let's call it, strict ordering
> both
> > are intended to improve safety by keeping the compiler from doing
> something
> > that's probably unsafe. And yet, you have adherents to swear that strict
> > aliasing kills valid compiler optimizations. Just as you believe that
> > strict ordering kills valid compiler optimizations.
> >
> > So what is the difference?
>
> Turning off "strict aliasing" will disable some optimization and may
> save some non-portable codes. The optimization is standard conforming.
>

That's not what the strict aliasing rule is.

Strict aliasing means that the compiler is free to assume that any two
pointers/references are not referring to the same object unless those
pointers are of the same or related types. But this also means that if you
pass two completely separate pointers to a function that just so happen to
be of the same type, the compiler *cannot assume* that they are different
objects. Which means that register usage patterns have to chance and so
forth.

When you turn off strict aliasing, you are telling the compiler that the
last assumption no longer has to be followed, that it should assume that
any two pointers/references *always* refer to different objects.

However, this also means that code designed for compilation when strict
aliasing is off cannot pass two pointers/references to the same object. Or
by contrast, code that works under strict aliasing rules is free to pass
two pointers/references to the same object. Which means that, if you
compile this code with strict aliasing off, the resulting code is *broken*.

In short, you can write C++ standards conforming code that is broken if you
turn off strict aliasing.

Just like you can write C++ standards conforming code (under P0145) which
*breaks* if you turn off the strict ordering rules of P0145. So what's the
difference?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_4088_1249739287.1448200464048
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, November 22, 2015 at 1:20:53 AM UTC-5, Kazutoshi SATODA 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/11/22 12:37 +0900, Nicol=
 Bolas wrote:
<br>&gt; On Saturday, November 21, 2015 at 3:55:51 PM UTC-5, Kazutoshi SATO=
DA wrote:
<br>&gt;&gt; On 2015/11/20 6:19 +0900, Gabriel Dos Reis wrote:=20
<br>&gt;&gt;&gt; I expect compilers to also offer switches for non-standard=
 evaluation=20
<br>&gt;&gt;&gt; order, just like some have -funsafe-math.=20
<br>&gt;&gt;
<br>&gt;&gt; I doubt the usefulness of such switches.=20
<br>&gt;&gt;
<br>&gt;&gt; Once the order is specified and people have been allowed to wr=
ite codes=20
<br>&gt;&gt; depending on that order, use of such compiler switches can res=
ult in=20
<br>&gt;&gt; completely different behavior with far higher possibility than=
=20
<br>&gt;&gt; -funsafe-math. AFAIK, the effect of -funsafe-math is often lim=
ited to=20
<br>&gt;&gt; the accuracy of floating arithmetics, which is implementation-=
defined in=20
<br>&gt;&gt; the first place.=20
<br>&gt;=20
<br>&gt; What is the difference between this switch and the switch to turn =
off=20
<br>&gt; strict aliasing? Strict aliasing and, let&#39;s call it, strict or=
dering both=20
<br>&gt; are intended to improve safety by keeping the compiler from doing =
something=20
<br>&gt; that&#39;s probably unsafe. And yet, you have adherents to swear t=
hat strict=20
<br>&gt; aliasing kills valid compiler optimizations. Just as you believe t=
hat=20
<br>&gt; strict ordering kills valid compiler optimizations.
<br>&gt;=20
<br>&gt; So what is the difference?
<br>
<br>Turning off &quot;strict aliasing&quot; will disable some optimization =
and may
<br>save some non-portable codes. The optimization is standard conforming.<=
br></blockquote><div><br>That&#39;s not what the strict aliasing rule is.<b=
r><br>Strict aliasing means that the compiler is free to assume that any tw=
o pointers/references are not referring to the same object unless those poi=
nters are of the same or related types. But this also means that if you pas=
s two completely separate pointers to a function that just so happen to be =
of the same type, the compiler <i>cannot assume</i> that they are different=
 objects. Which means that register usage patterns have to chance and so fo=
rth.<br><br>When you turn off strict aliasing, you are telling the compiler=
 that the last assumption no longer has to be followed, that it should assu=
me that any two pointers/references <i>always</i> refer to different object=
s.<br><br>However, this also means that code designed for compilation when =
strict aliasing is off cannot pass two pointers/references to the same obje=
ct. Or by contrast, code that works under strict aliasing rules is free to =
pass two pointers/references to the same object. Which means that, if you c=
ompile this code with strict aliasing off, the resulting code is <i>broken<=
/i>.<br><br>In short, you can write C++ standards conforming code that is b=
roken if you turn off strict aliasing.<br><br>Just like you can write C++ s=
tandards conforming code (under P0145) which <i>breaks</i> if you turn off =
the strict ordering rules of P0145. So what&#39;s the difference?</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_4088_1249739287.1448200464048--
------=_Part_4087_711956688.1448200464048--

.

------=_Part_201_683122415.1448202148966
Content-Type: multipart/alternative;
 boundary="----=_Part_202_2009310803.1448202148967"

------=_Part_202_2009310803.1448202148967
Content-Type: text/plain; charset=UTF-8



On Sunday, November 22, 2015 at 2:27:22 AM UTC-5, Kazutoshi SATODA wrote:
>
> On 2015/11/22 12:53 +0900, Nicol Bolas wrote:
> > On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazutoshi SATODA
> wrote:
> >> On 2015/11/20 5:24 +0900, Kazutoshi Satoda wrote:
> ...
> >>> Is these kind of concern already discussed?
> >>
> >> Now I found another trip report with a comment which includes what has
> >> been mentioned as the performance impact of P0145R0.
> ...
> >> It seems that this kind of concern has not been considered as a
> >> consequence of P0145R0 so far.
> >
> > So you see one comment on a trip report, and immediately assume that
> this
> > was the totality of the discussion at the meeting? That's a pretty huge
> > leap to be making.
>
> I said "it seems" with some supporting circumstance.


With very scant "supporting circumstance".


> If you know it
> isn't, please let me know. That is the question of my OP, which is not
> answered yet.
>
> >> The impact may increase in the future as compilers become wiser.
> >
> > If "compilers become wiser" about this, it would only be through knowing
> > more about what is being compiled. And if compilers know more about what
> is
> > being compiled, they will be better able to know when code is not
> > order-dependent.
> >
> > Indeed, the smarter the compiler gets, the more it knows about the code,
> > the *lower* the chance of needing to rely on non-strict ordering to get
> > appropriate optimizations. After all, if your code is not
> order-dependent,
> > and the compiler knows it, then there's no problem; the compiler can
> > reorder things because you can't tell the difference. The problem only
> > happens when your code is not order-dependent, but the compiler can only
> > guess that it is.
>
> My earlier reply to Bo Persson seems applicable here:
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/IJDqDAamBQAJ
> > The difference is, "the parameters are independent" can be assumed (now)
> > or must be proven (P0145R0). And it can't be proven if a (sub)expression
> > contains a call to unknown function via a pointer or virtual call.
>

.... so? I never claimed that compilers would develop omniscience, that they
could automagically prove every case that we assume now. My point is that
compilers getting smarter would improve the situation, not make it worse.

As for the statement itself, the strict aliasing analogy comes into play
here too. Strict aliasing favors cases that are provably correct (pointers
to unrelated types), rather than simply assuming that everything is fine.
The same should be true here: we should prefer optimizations that are
provably correct to optimizations that are assumed to be correct.

And this is even more important in cases when users have no way themselves
to know which is which. After all, a user certainly can't *know* that a
call via pointer/virtual function won't have some unintended effects. They
can assume that this will be the case. They can tell their users not to
pass in function pointers or override virtual functions in a way that
breaks this assumption. But they cannot *know*.


> And, AFAIK, compilers in present still can't prove much of independence
> between a call to function in different translation unit and a non-local
> variable.


If a compiler can't prove that, how can the compiler even *detect* common
sub-expressions, let alone eliminate them?

Even something like this:

func1(func2(), func3(func2()));

It's not OK for the compiler to eliminate the call to `func2`, unless the
compiler *knows* that `func2` is pure. And that's under *today's* C++
rules. And if the compiler knows that `func2` is pure... then the compiler
can optimize away the second call, *regardless* of the ordering of the
operations.

So exactly what cases would common subexpression elimination be allowed
under the current rules but forbidden under P0145?

So GCC has attributes "pure", "const" and they are proposed to
> be in the standard.
> ("The [[pure]] attribute" <
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0078r0.pdf>)
>
> Do you have any reasoning to foresee so much improvement of
> analyzability in the time frame of C++17 (the target of the proposal)?
> I don't.
>

.... I don't understand your point here. You said that the negative impacts
of P0145 would be increased with compiler intelligence. I showed the
opposite: that with more compiler intelligence and understanding, the
negative impacts of P0145 will be *decreased*, not increased. Then you say
that compilers won't be getting smarter in the future.

So which is it? Will compilers be getting smarter in the future or not?

--

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

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

<br><br>On Sunday, November 22, 2015 at 2:27:22 AM UTC-5, Kazutoshi SATODA =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015/11/22 12:53 +090=
0, Nicol Bolas wrote:
<br>&gt; On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazutoshi SATO=
DA wrote:
<br>&gt;&gt; On 2015/11/20 5:24 +0900, Kazutoshi Satoda wrote:
<br>...
<br>&gt;&gt;&gt; Is these kind of concern already discussed?
<br>&gt;&gt;
<br>&gt;&gt; Now I found another trip report with a comment which includes =
what has=20
<br>&gt;&gt; been mentioned as the performance impact of P0145R0.=20
<br>...
<br>&gt;&gt; It seems that this kind of concern has not been considered as =
a=20
<br>&gt;&gt; consequence of P0145R0 so far.
<br>&gt;=20
<br>&gt; So you see one comment on a trip report, and immediately assume th=
at this=20
<br>&gt; was the totality of the discussion at the meeting? That&#39;s a pr=
etty huge=20
<br>&gt; leap to be making.
<br>
<br>I said &quot;it seems&quot; with some supporting circumstance.</blockqu=
ote><div><br>With very scant &quot;supporting circumstance&quot;.<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;">If you know it
<br>isn&#39;t, please let me know. That is the question of my OP, which is =
not
<br>answered yet.
<br>
<br>&gt;&gt; The impact may increase in the future as compilers become wise=
r.
<br>&gt;=20
<br>&gt; If &quot;compilers become wiser&quot; about this, it would only be=
 through knowing=20
<br>&gt; more about what is being compiled. And if compilers know more abou=
t what is=20
<br>&gt; being compiled, they will be better able to know when code is not=
=20
<br>&gt; order-dependent.
<br>&gt;=20
<br>&gt; Indeed, the smarter the compiler gets, the more it knows about the=
 code,=20
<br>&gt; the *lower* the chance of needing to rely on non-strict ordering t=
o get=20
<br>&gt; appropriate optimizations. After all, if your code is not order-de=
pendent,=20
<br>&gt; and the compiler knows it, then there&#39;s no problem; the compil=
er can=20
<br>&gt; reorder things because you can&#39;t tell the difference. The prob=
lem only=20
<br>&gt; happens when your code is not order-dependent, but the compiler ca=
n only=20
<br>&gt; guess that it is.
<br>
<br>My earlier reply to Bo Persson seems applicable here:
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/E=
w_0zQl_yBg/IJDqDAamBQAJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals=
/Ew_0zQl_yBg/IJDqDAamBQAJ&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tps://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/IJDqDA=
amBQAJ&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg=
/std-<wbr>proposals/Ew_0zQl_yBg/<wbr>IJDqDAamBQAJ</a>
<br>&gt; The difference is, &quot;the parameters are independent&quot; can =
be assumed (now)
<br>&gt; or must be proven (P0145R0). And it can&#39;t be proven if a (sub)=
expression
<br>&gt; contains a call to unknown function via a pointer or virtual call.=
<br></blockquote><div><br>... so? I never claimed that compilers would deve=
lop omniscience, that they could automagically prove every case that we ass=
ume now. My point is that compilers getting smarter would improve the situa=
tion, not make it worse.<br><br>As for the statement itself, the strict ali=
asing analogy comes into play here too. Strict aliasing favors cases that a=
re provably correct (pointers to unrelated types), rather than simply assum=
ing that everything is fine. The same should be true here: we should prefer=
 optimizations that are provably correct to optimizations that are assumed =
to be correct.<br><br>And this is even more important in cases when users h=
ave no way themselves to know which is which. After all, a user certainly c=
an&#39;t <i>know</i> that a call via pointer/virtual function won&#39;t hav=
e some unintended effects. They can assume that this will be the case. They=
 can tell their users not to pass in function pointers or override virtual =
functions in a way that breaks this assumption. But they cannot <i>know</i>=
..<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">And, AFAIK, c=
ompilers in present still can&#39;t prove much of independence
<br>between a call to function in different translation unit and a non-loca=
l
<br>variable.</blockquote><div><br>If a compiler can&#39;t prove that, how =
can the compiler even <i>detect</i> common sub-expressions, let alone elimi=
nate them?<br><br>Even something like this:<br><br><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">func1</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">func2</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> func3</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
func2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()));=
</span></div></code></div><br>It&#39;s not OK for the compiler to eliminate=
 the call to `func2`, unless the compiler <i>knows</i> that `func2` is pure=
.. And that&#39;s under  <i>today&#39;s</i> C++ rules. And if the compiler k=
nows that `func2` is pure... then the compiler can optimize away the second=
 call, <i>regardless</i> of the ordering of the operations.<br><br>So exact=
ly what cases would common subexpression elimination be allowed under the c=
urrent rules but forbidden under P0145?<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;">So GCC has attributes &quot;pure&quot;, &quot;const&=
quot; and they are proposed to
<br>be in the standard.
<br>(&quot;The [[pure]] attribute&quot; &lt;<a href=3D"http://www.open-std.=
org/jtc1/sc22/wg21/docs/papers/2015/p0078r0.pdf" target=3D"_blank" rel=3D"n=
ofollow" 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%2Fp00=
78r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGhm3CxkbA_16XHegrswXds791Atw&#3=
9;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75=
http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2=
Fp0078r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGhm3CxkbA_16XHegrswXds791At=
w&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/paper=
s/2015/<wbr>p0078r0.pdf</a>&gt;)
<br>
<br>Do you have any reasoning to foresee so much improvement of
<br>analyzability in the time frame of C++17 (the target of the proposal)?
<br>I don&#39;t.<br></blockquote><div><br>... I don&#39;t understand your p=
oint here. You said that the negative impacts of P0145 would be increased w=
ith compiler intelligence. I showed the opposite: that with more compiler i=
ntelligence and understanding, the negative impacts of P0145 will be <i>dec=
reased</i>, not increased. Then you say that compilers won&#39;t be getting=
 smarter in the future.<br><br>So which is it? Will compilers be getting sm=
arter in the future or not?</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_202_2009310803.1448202148967--
------=_Part_201_683122415.1448202148966--

.

On 2015/11/22 22:54 +0900, Nicol Bolas wrote:
> On Sunday, November 22, 2015 at 1:20:53 AM UTC-5, Kazutoshi SATODA wrote:
>> On 2015/11/22 12:37 +0900, Nicol Bolas wrote:
>>> On Saturday, November 21, 2015 at 3:55:51 PM UTC-5, Kazutoshi SATODA wrote:
>>>> On 2015/11/20 6:19 +0900, Gabriel Dos Reis wrote:
>>>>> I expect compilers to also offer switches for non-standard evaluation
>>>>> order, just like some have -funsafe-math.
>>>>
>>>> I doubt the usefulness of such switches.
....
>>> What is the difference between this switch and the switch to turn off
>>> strict aliasing?
....
>> Turning off "strict aliasing" will disable some optimization and may
>> save some non-portable codes. The optimization is standard conforming.
>
> That's not what the strict aliasing rule is.
....
> When you turn off strict aliasing, you are telling the compiler that the
> last assumption no longer has to be followed, that it should assume that
> any two pointers/references *always* refer to different objects.

I assumed your "switch to turn off strict aliasing" is something like
"-fno-strict-aliasing" for GCC.
https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Optimize-Options.html#index-fstrict-aliasing-1049

But your definition is different. Your definition seems much like to put
C99 restrict everywhere. Then yes, I doubt usefulness of such switches
too with similar reasonings, even more strongly, as it will break almost
all programs.

But what compiler provides such option? Who are using the term "strict
aliasing" in such meaning? I have seen none.

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

.

On 2015/11/22 23:22 +0900, Nicol Bolas wrote:
> On Sunday, November 22, 2015 at 2:27:22 AM UTC-5, Kazutoshi SATODA wrote:
>> On 2015/11/22 12:53 +0900, Nicol Bolas wrote:
>>> On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazutoshi SATODA wrote:
....
>>>> The impact may increase in the future as compilers become wiser.
>>>
>>> If "compilers become wiser" about this, it would only be through knowing
>>> more about what is being compiled. And if compilers know more about what is
>>> being compiled, they will be better able to know when code is not
>>> order-dependent.
>>>
>>> Indeed, the smarter the compiler gets, the more it knows about the code,
>>> the *lower* the chance of needing to rely on non-strict ordering to get
>>> appropriate optimizations. After all, if your code is not order-dependent,
>>> and the compiler knows it, then there's no problem; the compiler can
>>> reorder things because you can't tell the difference. The problem only
>>> happens when your code is not order-dependent, but the compiler can only
>>> guess that it is.
>>
>> My earlier reply to Bo Persson seems applicable here:
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/IJDqDAamBQAJ
>>> The difference is, "the parameters are independent" can be assumed (now)
>>> or must be proven (P0145R0). And it can't be proven if a (sub)expression
>>> contains a call to unknown function via a pointer or virtual call.
>
> ... so? I never claimed that compilers would develop omniscience, that they
> could automagically prove every case that we assume now. My point is that
> compilers getting smarter would improve the situation, not make it worse.

Sorry for the confusion.

My "compilers become wiser" was about detecting purity of functions.
As compilers get smarter in detecting purity of functions, the chance of
CSE increase. And I think P0145R0 will reduce such increased chance.
Suppose that P0145R0 will reduce 1% of such chances of CSE. If chances
of CSE increase, the impact of P0145R0 (chance * 1%) will also increase.

Yes, the impact can be reduced if "compilers become wiser" in proving
independence of argument expressions. But I think it is far from status
quo, and will never reach to the point where it can assume that,
especially in the case with a call to unknown function.

> So exactly what cases would common subexpression elimination be allowed
> under the current rules but forbidden under P0145?

I think it is shown in the example at very beginning of this thread.
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/el_sLD4GBQAJ
If you don't think the example is not showing such cases, please point
out where and how the example is wrong.

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

.

------=_Part_4076_2025434338.1448207021863
Content-Type: multipart/alternative;
 boundary="----=_Part_4077_1298185989.1448207021869"

------=_Part_4077_1298185989.1448207021869
Content-Type: text/plain; charset=UTF-8

On Sunday, November 22, 2015 at 9:24:24 AM UTC-5, Kazutoshi SATODA wrote:
>
> On 2015/11/22 22:54 +0900, Nicol Bolas wrote:
> > On Sunday, November 22, 2015 at 1:20:53 AM UTC-5, Kazutoshi SATODA
> wrote:
> >> On 2015/11/22 12:37 +0900, Nicol Bolas wrote:
> >>> On Saturday, November 21, 2015 at 3:55:51 PM UTC-5, Kazutoshi SATODA
> wrote:
> >>>> On 2015/11/20 6:19 +0900, Gabriel Dos Reis wrote:
> >>>>> I expect compilers to also offer switches for non-standard
> evaluation
> >>>>> order, just like some have -funsafe-math.
> >>>>
> >>>> I doubt the usefulness of such switches.
> ...
> >>> What is the difference between this switch and the switch to turn off
> >>> strict aliasing?
> ...
> >> Turning off "strict aliasing" will disable some optimization and may
> >> save some non-portable codes. The optimization is standard conforming.
> >
> > That's not what the strict aliasing rule is.
> ...
> > When you turn off strict aliasing, you are telling the compiler that the
> > last assumption no longer has to be followed, that it should assume that
> > any two pointers/references *always* refer to different objects.
>
> I assumed your "switch to turn off strict aliasing" is something like
> "-fno-strict-aliasing" for GCC.
>
> https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Optimize-Options.html#index-fstrict-aliasing-1049
>
> But your definition is different. Your definition seems much like to put
> C99 restrict everywhere. Then yes, I doubt usefulness of such switches
> too with similar reasonings, even more strongly, as it will break almost
> all programs.
>
> But what compiler provides such option? Who are using the term "strict
> aliasing" in such meaning? I have seen none.
>

No, I got that backwards. You're right.

Strict aliasing has two parts. One part is what I talked about; namely,
what the compiler is allowed to assume that code means.

The other part is the part that says, "doing certain things means undefined
behavior." For example, type-punning is forbidden by strict aliasing, and
doing it leads to undefined behavior. However, these things are forbidden
*precisely* to allow the first part: to allow the compiler to make
assumptions about something.

After all, given pointers to two unrelated types, if you allow
type-punning, then the assumption that these pointers point to different
objects may not be true. So the user prohibition part of strict aliasing is
what *allows* the compiler assumption part to make sense.

When you use -fno-strict-aliasing, as you said, the compiler must assume
nothing about whether pointers alias. Or more to the point, when not using
strict aliasing, compilers must assume that pretty much any two pointers
can alias.

However, the *reason* why people would use that switch is because they want
type punning, and they want to shut up GCC/Clang's warnings about it not
being legal C++.

--

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

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

On Sunday, November 22, 2015 at 9:24:24 AM UTC-5, Kazutoshi SATODA 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/11/22 22:54 +0900, Nicol=
 Bolas wrote:
<br>&gt; On Sunday, November 22, 2015 at 1:20:53 AM UTC-5, Kazutoshi SATODA=
 wrote:
<br>&gt;&gt; On 2015/11/22 12:37 +0900, Nicol Bolas wrote:=20
<br>&gt;&gt;&gt; On Saturday, November 21, 2015 at 3:55:51 PM UTC-5, Kazuto=
shi SATODA wrote:=20
<br>&gt;&gt;&gt;&gt; On 2015/11/20 6:19 +0900, Gabriel Dos Reis wrote:=20
<br>&gt;&gt;&gt;&gt;&gt; I expect compilers to also offer switches for non-=
standard evaluation=20
<br>&gt;&gt;&gt;&gt;&gt; order, just like some have -funsafe-math.=20
<br>&gt;&gt;&gt;&gt;=20
<br>&gt;&gt;&gt;&gt; I doubt the usefulness of such switches.=20
<br>...
<br>&gt;&gt;&gt; What is the difference between this switch and the switch =
to turn off=20
<br>&gt;&gt;&gt; strict aliasing?
<br>...
<br>&gt;&gt; Turning off &quot;strict aliasing&quot; will disable some opti=
mization and may=20
<br>&gt;&gt; save some non-portable codes. The optimization is standard con=
forming.
<br>&gt;=20
<br>&gt; That&#39;s not what the strict aliasing rule is.
<br>...
<br>&gt; When you turn off strict aliasing, you are telling the compiler th=
at the=20
<br>&gt; last assumption no longer has to be followed, that it should assum=
e that=20
<br>&gt; any two pointers/references *always* refer to different objects.
<br>
<br>I assumed your &quot;switch to turn off strict aliasing&quot; is someth=
ing like
<br>&quot;-fno-strict-aliasing&quot; for GCC.
<br><a href=3D"https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Optimize-Option=
s.html#index-fstrict-aliasing-1049" target=3D"_blank" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgc=
c.gnu.org%2Fonlinedocs%2Fgcc-5.2.0%2Fgcc%2FOptimize-Options.html%23index-fs=
trict-aliasing-1049\46sa\75D\46sntz\0751\46usg\75AFQjCNE_dvDrBlwgIPMJMuNwRw=
gSF_0LSQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.=
com/url?q\75https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc-5.2.0%2Fgcc%2FOpti=
mize-Options.html%23index-fstrict-aliasing-1049\46sa\75D\46sntz\0751\46usg\=
75AFQjCNE_dvDrBlwgIPMJMuNwRwgSF_0LSQ&#39;;return true;">https://gcc.gnu.org=
/<wbr>onlinedocs/gcc-5.2.0/gcc/<wbr>Optimize-Options.html#index-<wbr>fstric=
t-aliasing-1049</a>
<br>
<br>But your definition is different. Your definition seems much like to pu=
t
<br>C99 restrict everywhere. Then yes, I doubt usefulness of such switches
<br>too with similar reasonings, even more strongly, as it will break almos=
t
<br>all programs.
<br>
<br>But what compiler provides such option? Who are using the term &quot;st=
rict
<br>aliasing&quot; in such meaning? I have seen none.
<br></blockquote><div><br>No, I got that backwards. You&#39;re right.<br><b=
r>Strict aliasing has two parts. One part is what I talked about; namely, w=
hat the compiler is allowed to assume that code means.<br><br>The other par=
t is the part that says, &quot;doing certain things means undefined behavio=
r.&quot; For example, type-punning is forbidden by strict aliasing, and doi=
ng it leads to undefined behavior. However, these things are forbidden <i>p=
recisely</i> to allow the first part: to allow the compiler to make assumpt=
ions about something.<br><br>After all, given pointers to two unrelated typ=
es, if you allow type-punning, then the assumption that these pointers poin=
t to different objects may not be true. So the user prohibition part of str=
ict aliasing is what <i>allows</i> the compiler assumption part to make sen=
se.<br><br>When you use -fno-strict-aliasing, as you said, the compiler mus=
t assume nothing about
 whether pointers alias. Or more to the point, when not using strict=20
aliasing, compilers must assume that pretty much any two pointers can=20
alias.<br><br>However, the <i>reason</i> why people would use that switch i=
s because they want type punning, and they want to shut up GCC/Clang&#39;s =
warnings about it not being legal C++.<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_4077_1298185989.1448207021869--
------=_Part_4076_2025434338.1448207021863--

.

------=_Part_329_1500707426.1448207547156
Content-Type: multipart/alternative;
 boundary="----=_Part_330_1947135769.1448207547156"

------=_Part_330_1947135769.1448207547156
Content-Type: text/plain; charset=UTF-8



On Sunday, November 22, 2015 at 10:20:18 AM UTC-5, Kazutoshi SATODA wrote:
>
> On 2015/11/22 23:22 +0900, Nicol Bolas wrote:
> > On Sunday, November 22, 2015 at 2:27:22 AM UTC-5, Kazutoshi SATODA
> wrote:
> >> On 2015/11/22 12:53 +0900, Nicol Bolas wrote:
> >>> On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazutoshi SATODA
> wrote:
> ...
> >>>> The impact may increase in the future as compilers become wiser.
> >>>
> >>> If "compilers become wiser" about this, it would only be through
> knowing
> >>> more about what is being compiled. And if compilers know more about
> what is
> >>> being compiled, they will be better able to know when code is not
> >>> order-dependent.
> >>>
> >>> Indeed, the smarter the compiler gets, the more it knows about the
> code,
> >>> the *lower* the chance of needing to rely on non-strict ordering to
> get
> >>> appropriate optimizations. After all, if your code is not
> order-dependent,
> >>> and the compiler knows it, then there's no problem; the compiler can
> >>> reorder things because you can't tell the difference. The problem only
> >>> happens when your code is not order-dependent, but the compiler can
> only
> >>> guess that it is.
> >>
> >> My earlier reply to Bo Persson seems applicable here:
> >>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/IJDqDAamBQAJ
> >>> The difference is, "the parameters are independent" can be assumed
> (now)
> >>> or must be proven (P0145R0). And it can't be proven if a
> (sub)expression
> >>> contains a call to unknown function via a pointer or virtual call.
> >
> > ... so? I never claimed that compilers would develop omniscience, that
> they
> > could automagically prove every case that we assume now. My point is
> that
> > compilers getting smarter would improve the situation, not make it
> worse.
>
> Sorry for the confusion.
>
> My "compilers become wiser" was about detecting purity of functions.
> As compilers get smarter in detecting purity of functions, the chance of
> CSE increase. And I think P0145R0 will reduce such increased chance.
>

How? As shown below, your initial example very much can be optimized under
P0145. So exactly how will P0145 reduce the ability for CSE-based
optimizations, given greater compiler knowledge of function purity?

> So exactly what cases would common subexpression elimination be allowed
> > under the current rules but forbidden under P0145?
>
> I think it is shown in the example at very beginning of this thread.
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/el_sLD4GBQAJ
> If you don't think the example is not showing such cases, please point
> out where and how the example is wrong.
>

I don't have to; Gabriel Dos Reis did ;)

As he said:
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/jf6_DjQJBQAJ>

the compiler knows it can invoke the "as if" rule and reorder as it pleases
> -- there is no way to tell.


If `pure` is a pure function, and the compiler knows it is a pure function,
and you invoke it twice, and the compiler knows that the argument you
invoke it with is the same in both cases... then the compiler can invoke
the "as if" rule and optimize out the second call.

This is true *regardless* of whether P0145 is in force or not. There is
nothing in that document that would prevent this optimization.

The only case where it would matter is if the compiler doesn't know that
the function is pure. And if it doesn't *know* that the function is pure,
then it has *absolutely no right* to optimize out the second call.

Compilers should not be making optimizations based on what it thinks it
knows about 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Sunday, November 22, 2015 at 10:20:18 AM UTC-5, Kazutoshi SATODA=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015/11/22 23:22 +09=
00, Nicol Bolas wrote:
<br>&gt; On Sunday, November 22, 2015 at 2:27:22 AM UTC-5, Kazutoshi SATODA=
 wrote:
<br>&gt;&gt; On 2015/11/22 12:53 +0900, Nicol Bolas wrote:=20
<br>&gt;&gt;&gt; On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazuto=
shi SATODA wrote:=20
<br>...
<br>&gt;&gt;&gt;&gt; The impact may increase in the future as compilers bec=
ome wiser.=20
<br>&gt;&gt;&gt;=20
<br>&gt;&gt;&gt; If &quot;compilers become wiser&quot; about this, it would=
 only be through knowing=20
<br>&gt;&gt;&gt; more about what is being compiled. And if compilers know m=
ore about what is=20
<br>&gt;&gt;&gt; being compiled, they will be better able to know when code=
 is not=20
<br>&gt;&gt;&gt; order-dependent.=20
<br>&gt;&gt;&gt;=20
<br>&gt;&gt;&gt; Indeed, the smarter the compiler gets, the more it knows a=
bout the code,=20
<br>&gt;&gt;&gt; the *lower* the chance of needing to rely on non-strict or=
dering to get=20
<br>&gt;&gt;&gt; appropriate optimizations. After all, if your code is not =
order-dependent,=20
<br>&gt;&gt;&gt; and the compiler knows it, then there&#39;s no problem; th=
e compiler can=20
<br>&gt;&gt;&gt; reorder things because you can&#39;t tell the difference. =
The problem only=20
<br>&gt;&gt;&gt; happens when your code is not order-dependent, but the com=
piler can only=20
<br>&gt;&gt;&gt; guess that it is.=20
<br>&gt;&gt;
<br>&gt;&gt; My earlier reply to Bo Persson seems applicable here:=20
<br>&gt;&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/Ew_0zQl_yBg/IJDqDAamBQAJ" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-=
proposals/Ew_0zQl_yBg/IJDqDAamBQAJ&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_=
yBg/IJDqDAamBQAJ&#39;;return true;">https://groups.google.com/a/<wbr>isocpp=
..org/d/msg/std-<wbr>proposals/Ew_0zQl_yBg/<wbr>IJDqDAamBQAJ</a>=20
<br>&gt;&gt;&gt; The difference is, &quot;the parameters are independent&qu=
ot; can be assumed (now)=20
<br>&gt;&gt;&gt; or must be proven (P0145R0). And it can&#39;t be proven if=
 a (sub)expression=20
<br>&gt;&gt;&gt; contains a call to unknown function via a pointer or virtu=
al call.
<br>&gt;=20
<br>&gt; ... so? I never claimed that compilers would develop omniscience, =
that they=20
<br>&gt; could automagically prove every case that we assume now. My point =
is that=20
<br>&gt; compilers getting smarter would improve the situation, not make it=
 worse.
<br>
<br>Sorry for the confusion.
<br>
<br>My &quot;compilers become wiser&quot; was about detecting purity of fun=
ctions.
<br>As compilers get smarter in detecting purity of functions, the chance o=
f
<br>CSE increase. And I think P0145R0 will reduce such increased chance.<br=
></blockquote><div><br>How? As shown below, your initial example very much =
can be optimized under P0145. So exactly how will P0145 reduce the ability =
for CSE-based optimizations, given greater compiler knowledge of function p=
urity?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; So exactly what cases would common subexpression elimination be allowe=
d=20
<br>&gt; under the current rules but forbidden under P0145?
<br>
<br>I think it is shown in the example at very beginning of this thread.
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/E=
w_0zQl_yBg/el_sLD4GBQAJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals=
/Ew_0zQl_yBg/el_sLD4GBQAJ&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tps://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/el_sLD=
4GBQAJ&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg=
/std-<wbr>proposals/Ew_0zQl_yBg/el_<wbr>sLD4GBQAJ</a>
<br>If you don&#39;t think the example is not showing such cases, please po=
int
<br>out where and how the example is wrong.
<br></blockquote><div><br>I don&#39;t have to; Gabriel Dos Reis did ;)<br><=
br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew=
_0zQl_yBg/jf6_DjQJBQAJ">As he said:</a><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">the compiler knows it can invoke the &quot;as=
 if&quot; rule and reorder as it pleases -- there is no way to tell.</block=
quote><div><br>If `pure` is a pure function, and the compiler knows it is a=
 pure function, and you invoke it twice, and the compiler knows that the ar=
gument you invoke it with is the same in both cases... then the compiler ca=
n invoke the &quot;as if&quot; rule and optimize out the second call.<br><b=
r>This is true <i>regardless</i> of whether P0145 is in force or not. There=
 is nothing in that document that would prevent this optimization.<br><br>T=
he only case where it would matter is if the compiler doesn&#39;t know that=
 the function is pure. And if it doesn&#39;t <i>know</i> that the function =
is pure, then it has <i>absolutely no right</i> to optimize out the second =
call.<br><br>Compilers should not be making optimizations based on what it =
thinks it knows about behavior.<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_330_1947135769.1448207547156--
------=_Part_329_1500707426.1448207547156--

.

On 2015/11/23 0:52 +0900, Nicol Bolas wrote:
> On Sunday, November 22, 2015 at 10:20:18 AM UTC-5, Kazutoshi SATODA wrote:
>> On 2015/11/22 23:22 +0900, Nicol Bolas wrote:
....
>>> So exactly what cases would common subexpression elimination be allowed
>>> under the current rules but forbidden under P0145?
>>
>> I think it is shown in the example at very beginning of this thread.
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/el_sLD4GBQAJ
>> If you don't think the example is not showing such cases, please point
>> out where and how the example is wrong.
>
> If `pure` is a pure function, and the compiler knows it is a pure function,
> and you invoke it twice, and the compiler knows that the argument you
> invoke it with is the same in both cases... then the compiler can invoke
> the "as if" rule and optimize out the second call.
>
> This is true *regardless* of whether P0145 is in force or not. There is
> nothing in that document that would prevent this optimization.

You seem missing the point of the example where the function pure() is
called with argument non_local (non-const variable). That variable can
be modified by the call of unknown() which P0145R0 specify to intervene
the two calls of pure(non_local). The compiler can't perform CSE if the
argument non_local can be different for these two calls.

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

.

------=_Part_1009_1685003330.1448209269685
Content-Type: multipart/alternative;
 boundary="----=_Part_1010_505793934.1448209269685"

------=_Part_1010_505793934.1448209269685
Content-Type: text/plain; charset=UTF-8

On Sunday, November 22, 2015 at 10:52:27 AM UTC-5, Nicol Bolas wrote:
>
> On Sunday, November 22, 2015 at 10:20:18 AM UTC-5, Kazutoshi SATODA wrote:
>>
>> On 2015/11/22 23:22 +0900, Nicol Bolas wrote:
>> > On Sunday, November 22, 2015 at 2:27:22 AM UTC-5, Kazutoshi SATODA
>> wrote:
>> >> On 2015/11/22 12:53 +0900, Nicol Bolas wrote:
>> >>> On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazutoshi SATODA
>> wrote:
>> ...
>> >>>> The impact may increase in the future as compilers become wiser.
>> >>>
>> >>> If "compilers become wiser" about this, it would only be through
>> knowing
>> >>> more about what is being compiled. And if compilers know more about
>> what is
>> >>> being compiled, they will be better able to know when code is not
>> >>> order-dependent.
>> >>>
>> >>> Indeed, the smarter the compiler gets, the more it knows about the
>> code,
>> >>> the *lower* the chance of needing to rely on non-strict ordering to
>> get
>> >>> appropriate optimizations. After all, if your code is not
>> order-dependent,
>> >>> and the compiler knows it, then there's no problem; the compiler can
>> >>> reorder things because you can't tell the difference. The problem
>> only
>> >>> happens when your code is not order-dependent, but the compiler can
>> only
>> >>> guess that it is.
>> >>
>> >> My earlier reply to Bo Persson seems applicable here:
>> >>
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/IJDqDAamBQAJ
>> >>> The difference is, "the parameters are independent" can be assumed
>> (now)
>> >>> or must be proven (P0145R0). And it can't be proven if a
>> (sub)expression
>> >>> contains a call to unknown function via a pointer or virtual call.
>> >
>> > ... so? I never claimed that compilers would develop omniscience, that
>> they
>> > could automagically prove every case that we assume now. My point is
>> that
>> > compilers getting smarter would improve the situation, not make it
>> worse.
>>
>> Sorry for the confusion.
>>
>> My "compilers become wiser" was about detecting purity of functions.
>> As compilers get smarter in detecting purity of functions, the chance of
>> CSE increase. And I think P0145R0 will reduce such increased chance.
>>
>
> How? As shown below, your initial example very much can be optimized under
> P0145. So exactly how will P0145 reduce the ability for CSE-based
> optimizations, given greater compiler knowledge of function purity?
>
> > So exactly what cases would common subexpression elimination be allowed
>> > under the current rules but forbidden under P0145?
>>
>> I think it is shown in the example at very beginning of this thread.
>>
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/el_sLD4GBQAJ
>> If you don't think the example is not showing such cases, please point
>> out where and how the example is wrong.
>>
>
> I don't have to; Gabriel Dos Reis did ;)
>
> As he said:
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/jf6_DjQJBQAJ>
>
> the compiler knows it can invoke the "as if" rule and reorder as it
>> pleases -- there is no way to tell.
>
>
> If `pure` is a pure function, and the compiler knows it is a pure
> function, and you invoke it twice, and the compiler knows that the argument
> you invoke it with is the same in both cases... then the compiler can
> invoke the "as if" rule and optimize out the second call.
>
> This is true *regardless* of whether P0145 is in force or not. There is
> nothing in that document that would prevent this optimization.
>
> The only case where it would matter is if the compiler doesn't know that
> the function is pure. And if it doesn't *know* that the function is pure,
> then it has *absolutely no right* to optimize out the second call.
>
> Compilers should not be making optimizations based on what it thinks it
> knows about behavior.
>

I just noticed that `unknown` was a global function of unknown purity which
theoretically could have changed "non_local". So the conditions for this
problem are:

1: A pure function call, using non-local parameters.
2: A function call to a function of unknown purity.
3: A pure function call, using the same non-local parameters as before.

Exactly how often is that likely to happen? Pure functions aren't exactly
the most common thing, particularly by the definition proposed in the paper
you cited (no pointer/references in arguments, so no member functions).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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_1010_505793934.1448209269685
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, November 22, 2015 at 10:52:27 AM UTC-5, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">On Sunday, November 22, 2015 at 10:2=
0:18 AM UTC-5, Kazutoshi SATODA wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x">On 2015/11/22 23:22 +0900, Nicol Bolas wrote:
<br>&gt; On Sunday, November 22, 2015 at 2:27:22 AM UTC-5, Kazutoshi SATODA=
 wrote:
<br>&gt;&gt; On 2015/11/22 12:53 +0900, Nicol Bolas wrote:=20
<br>&gt;&gt;&gt; On Saturday, November 21, 2015 at 3:56:00 PM UTC-5, Kazuto=
shi SATODA wrote:=20
<br>...
<br>&gt;&gt;&gt;&gt; The impact may increase in the future as compilers bec=
ome wiser.=20
<br>&gt;&gt;&gt;=20
<br>&gt;&gt;&gt; If &quot;compilers become wiser&quot; about this, it would=
 only be through knowing=20
<br>&gt;&gt;&gt; more about what is being compiled. And if compilers know m=
ore about what is=20
<br>&gt;&gt;&gt; being compiled, they will be better able to know when code=
 is not=20
<br>&gt;&gt;&gt; order-dependent.=20
<br>&gt;&gt;&gt;=20
<br>&gt;&gt;&gt; Indeed, the smarter the compiler gets, the more it knows a=
bout the code,=20
<br>&gt;&gt;&gt; the *lower* the chance of needing to rely on non-strict or=
dering to get=20
<br>&gt;&gt;&gt; appropriate optimizations. After all, if your code is not =
order-dependent,=20
<br>&gt;&gt;&gt; and the compiler knows it, then there&#39;s no problem; th=
e compiler can=20
<br>&gt;&gt;&gt; reorder things because you can&#39;t tell the difference. =
The problem only=20
<br>&gt;&gt;&gt; happens when your code is not order-dependent, but the com=
piler can only=20
<br>&gt;&gt;&gt; guess that it is.=20
<br>&gt;&gt;
<br>&gt;&gt; My earlier reply to Bo Persson seems applicable here:=20
<br>&gt;&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/Ew_0zQl_yBg/IJDqDAamBQAJ" rel=3D"nofollow" target=3D"_blank" onmous=
edown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-=
proposals/Ew_0zQl_yBg/IJDqDAamBQAJ&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_=
yBg/IJDqDAamBQAJ&#39;;return true;">https://groups.google.com/a/<wbr>isocpp=
..org/d/msg/std-<wbr>proposals/Ew_0zQl_yBg/<wbr>IJDqDAamBQAJ</a>=20
<br>&gt;&gt;&gt; The difference is, &quot;the parameters are independent&qu=
ot; can be assumed (now)=20
<br>&gt;&gt;&gt; or must be proven (P0145R0). And it can&#39;t be proven if=
 a (sub)expression=20
<br>&gt;&gt;&gt; contains a call to unknown function via a pointer or virtu=
al call.
<br>&gt;=20
<br>&gt; ... so? I never claimed that compilers would develop omniscience, =
that they=20
<br>&gt; could automagically prove every case that we assume now. My point =
is that=20
<br>&gt; compilers getting smarter would improve the situation, not make it=
 worse.
<br>
<br>Sorry for the confusion.
<br>
<br>My &quot;compilers become wiser&quot; was about detecting purity of fun=
ctions.
<br>As compilers get smarter in detecting purity of functions, the chance o=
f
<br>CSE increase. And I think P0145R0 will reduce such increased chance.<br=
></blockquote><div><br>How? As shown below, your initial example very much =
can be optimized under P0145. So exactly how will P0145 reduce the ability =
for CSE-based optimizations, given greater compiler knowledge of function p=
urity?<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">
&gt; So exactly what cases would common subexpression elimination be allowe=
d=20
<br>&gt; under the current rules but forbidden under P0145?
<br>
<br>I think it is shown in the example at very beginning of this thread.
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/E=
w_0zQl_yBg/el_sLD4GBQAJ" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals=
/Ew_0zQl_yBg/el_sLD4GBQAJ&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tps://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/el_sLD=
4GBQAJ&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg=
/std-<wbr>proposals/Ew_0zQl_yBg/el_<wbr>sLD4GBQAJ</a>
<br>If you don&#39;t think the example is not showing such cases, please po=
int
<br>out where and how the example is wrong.
<br></blockquote><div><br>I don&#39;t have to; Gabriel Dos Reis did ;)<br><=
br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew=
_0zQl_yBg/jf6_DjQJBQAJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals/=
Ew_0zQl_yBg/jf6_DjQJBQAJ&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msg/std-proposals/Ew_0zQl_yBg/jf6_DjQ=
JBQAJ&#39;;return true;">As he said:</a><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">the compiler knows it can invoke the &quot;as if&quo=
t; rule and reorder as it pleases -- there is no way to tell.</blockquote><=
div><br>If `pure` is a pure function, and the compiler knows it is a pure f=
unction, and you invoke it twice, and the compiler knows that the argument =
you invoke it with is the same in both cases... then the compiler can invok=
e the &quot;as if&quot; rule and optimize out the second call.<br><br>This =
is true <i>regardless</i> of whether P0145 is in force or not. There is not=
hing in that document that would prevent this optimization.<br><br>The only=
 case where it would matter is if the compiler doesn&#39;t know that the fu=
nction is pure. And if it doesn&#39;t <i>know</i> that the function is pure=
, then it has <i>absolutely no right</i> to optimize out the second call.<b=
r><br>Compilers should not be making optimizations based on what it thinks =
it knows about behavior.<br></div></div></blockquote><div><br>I just notice=
d that `unknown` was a global function of unknown purity which theoreticall=
y could have changed &quot;non_local&quot;. So the conditions for this prob=
lem are:<br><br>1: A pure function call, using non-local parameters.<br>2: =
A function call to a function of unknown purity.<br>3: A pure function call=
, using the same non-local parameters as before.<br><br>Exactly how often i=
s that likely to happen? Pure functions aren&#39;t exactly the most common =
thing, particularly by the definition proposed in the paper you cited (no p=
ointer/references in arguments, so no member functions).<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_1010_505793934.1448209269685--
------=_Part_1009_1685003330.1448209269685--

.

On 2015/11/23 1:21 +0900, Nicol Bolas wrote:
> I just noticed that `unknown` was a global function of unknown purity which
> theoretically could have changed "non_local". So the conditions for this
> problem are:
>
> 1: A pure function call, using non-local parameters.
> 2: A function call to a function of unknown purity.
> 3: A pure function call, using the same non-local parameters as before.

It's close. Please read below for more cases.

> Exactly how often is that likely to happen? Pure functions aren't exactly
> the most common thing, particularly by the definition proposed in the paper
> you cited (no pointer/references in arguments, so no member functions).

I don't know exactly, but my guess is shown at the part "While the
above code looks a fiction, ..." of my first post.

Note that the "purity" of the condition of these case is not limited to
"pure function." It is enough that a function (as replacement of pure()
in the example) is "pure enough" to perform CSE. For example, it can
read arbitrary objects via pointers or references.

  int f(int a1, int a2, int a3);

  int g(std::map<int, int> const& m, int (*unknown)())
  {
    return f(m.at(0), unknown(), m.at(0));
  }

The two lookup "m.at(0)" can be eliminated into one under the current
rule, but it is not allowed after adoption of P0145R0.

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

.

------=_Part_1575_1974849043.1449201322444
Content-Type: multipart/alternative;
 boundary="----=_Part_1576_310308455.1449201322444"

------=_Part_1576_310308455.1449201322444
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_1576_310308455.1449201322444
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div style=3D"overflow: auto"><div style=3D"max-heigh=
t: 10000px;"><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"=
 rel=3D"nofollow">P0145R0</a>. As a user of C++, I urge EWG and CWG to reco=
nsider 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 wording, please.)</li><li>As men=
tioned above, it may harm to optimization.</li><li>The
 reason represented by the proposal is unsound. It harms teachability=20
and makes it hard to get consensus on conventional (&quot;best&quot;) pract=
ice.<br></li></ol>I feels the first 2 points should be acknowledged here.<b=
r><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 e=
xpression</b> <i>intended </i>by the author of the code.<br><br>For this pu=
rpose, I currently explicitly <a href=3D"https://bitbucket.org/FrankHB/ysli=
b/src/82a019b2ec3a51c32a92ceb674020ae92fe2d256/YBase/include/ydef.h?at=3Dma=
ster&amp;fileviewer=3Dfile-view-default#ydef.h-938" target=3D"_blank" rel=
=3D"nofollow">used the unsequenced function parameter rule</a> and <a href=
=3D"https://bitbucket.org/FrankHB/yslib/src/82a019b2ec3a51c32a92ceb674020ae=
92fe2d256/YBase/include/ydef.h?at=3Dmaster&amp;fileviewer=3Dfile-view-defau=
lt#ydef.h-956" target=3D"_blank" rel=3D"nofollow">a macro wrapper</a> for r=
eadability. (It would probably be better with <a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html" target=3D"_blank" rel=
=3D"nofollow">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 styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code><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></di=
v></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"colo=
r:#800">#pragma</span><span style=3D"color:#000"> GCC diagnostic pop<br></s=
pan></div></code></div><br>For the 4th point, one key point is: <b>it is no=
nsense to support bad code</b>.<br><br>If
 the author want the clear evaluation order, do extract the=20
subexpression as a single statement (followed by &#39;;&#39;). This=20
transformation should not be a problem on well-formed code since even=20
constexpr functions now support multiple statements in the body, and=20
there are lambdas.<br><br>What if the author do not know what order they wa=
nt ... who allow they to code such spaghetti?<br><br>I
 don&#39;t think anyone should be encourage to write such code except for=
=20
the purpose of testing the implementation (e.g. [-Wsequenced] or ubsan).
 Any senior C++ user would probable agree this point easily by their=20
experience. The code should be reject by the contemporary style because=20
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">Herb Sutter&#39;s p=
oll</a>.<br><br>To
 reduce the potential risks, a programmer who don&#39;t have enough common=
=20
sense about sequence rules (also imply the definition of &quot;undefined=20
behavior&quot;), should not be granted permission of modify the C++ code ba=
se
 in a serious project. This is similar to C which uses similar UB rules=20
with &quot;sequence point&quot; wording. <b>These knowledge should be at ve=
ry basic level of the language.</b>
 The unsequenced evaluation rules are excellent examples about the=20
position and importance of these rules. Other subtle rules are usually=20
more difficult to learn. That&#39;s why I think the change harms the=20
teachability: we&#39;d lost a chance to tell the newbies to discipline=20
themselves about being responsible to what they&#39;d write, which is hard=
=20
to rescue later. This is super important for a language has so many=20
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" target=3D"_blank" rel=3D"nof=
ollow">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=20
like above.<br><br></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1576_310308455.1449201322444--
------=_Part_1575_1974849043.1449201322444--

.