------=_Part_910_30162752.1355048978288
Content-Type: text/plain; charset=ISO-8859-1

I'd like to suggest changes to the Standard for the purpose of tighter
expression sequencing. Namely,

Firstly, each expression would be fully evaluated in it's own right before
evaluating other expressions- that is, the compiler no longer has the right
to interleave them. This would make unspecified many things which are
currently undefined behaviour.
Secondly, the compiler is obliged to evaluate them in the order they are
parsed according to the grammar- that is, left-associative expressions are
parsed left-associative, function arguments from left to right, assignments
right to left.

--




------=_Part_910_30162752.1355048978288
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'd like to suggest changes to the Standard for the purpose of tighter expr=
ession sequencing. Namely,<div><br></div><div>Firstly, each expression woul=
d be fully evaluated in it's own right before evaluating other expressions-=
 that is, the compiler no longer has the right to interleave them. This wou=
ld make unspecified many things which are currently undefined behaviour.</d=
iv><div>Secondly, the compiler is obliged to evaluate them in the order the=
y are parsed according to the grammar- that is, left-associative expression=
s are parsed left-associative, function arguments from left to right, assig=
nments right to left.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_910_30162752.1355048978288--

.

On Sun, Dec 09, 2012 at 02:29:38AM -0800, DeadMG wrote:
> I'd like to suggest changes to the Standard for the purpose of tighter
> expression sequencing. Namely,

Wouldn't that have a significant performance impact as the compiler
will be prevented from doing many useful optimisations?


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--




.

On 09/12/12 10:53, Christof Meerwald wrote:
> On Sun, Dec 09, 2012 at 02:29:38AM -0800, DeadMG wrote:
>> I'd like to suggest changes to the Standard for the purpose of tighter
>> expression sequencing. Namely,
> Wouldn't that have a significant performance impact as the compiler
> will be prevented from doing many useful optimisations?

This is indeed the usual argument for not tightening up this area. I
would love to see a document by a compiler author, preferably with
experiments, showing if these features really are providing useful
performance gains.

Without concrete numbers, this suggestion will I am sure (unfortunately)
go nowhere.

Chris

--




.

On 12/09/2012 11:29 AM, DeadMG wrote:
> I'd like to suggest changes to the Standard for the purpose of tighter expression sequencing. Namely,
>
> Firstly, each expression would be fully evaluated in it's own right
> before evaluating other expressions- that is, the compiler no longer
> has the right to interleave them. This would make unspecified many
> things which are currently undefined behaviour. Secondly, the
> compiler is obliged to evaluate them in the order they are parsed
> according to the grammar- that is, left-associative expressions are
> parsed left-associative, function arguments from left to right,
> assignments right to left.

The current sequencing rules in the C++ standard have 20+ years
of heritage from C.  If you consider writing up a proposal for such a
change, please do include results of performance experiments obtained
by modifying an optimizing compiler to observe these restrictions, also
considering various calling conventions.

Unless you're prepared to do that, such a proposal is a non-starter.

Jens

--




.

------=_Part_29_842034.1355067987979
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, December 9, 2012 11:29:38 AM UTC+1, DeadMG wrote:
>
> I'd like to suggest changes to the Standard for the purpose of tighter
> expression sequencing. Namely,
>
> Firstly, each expression would be fully evaluated in it's own right before
> evaluating other expressions- that is, the compiler no longer has the right
> to interleave them. This would make unspecified many things which are
> currently undefined behaviour.
> Secondly, the compiler is obliged to evaluate them in the order they are
> parsed according to the grammar- that is, left-associative expressions are
> parsed left-associative, function arguments from left to right, assignments
> right to left.
>

A bit different: I'd like default function arguments to be able to refer to
other function arguments. This is related in that it would force a
sequencing at least between the evaluation of the default argument and the
evaluation of those arguments it references. In this particular case, there
is no performance to lose. And it can be seen as a first step into
sequencing more strictly.

--




------=_Part_29_842034.1355067987979
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, December 9, 2012 11:29:38 AM UTC+1, DeadMG wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">I'd like to suggest changes to the Standard f=
or the purpose of tighter expression sequencing. Namely,<div><br></div><div=
>Firstly, each expression would be fully evaluated in it's own right before=
 evaluating other expressions- that is, the compiler no longer has the righ=
t to interleave them. This would make unspecified many things which are cur=
rently undefined behaviour.</div><div>Secondly, the compiler is obliged to =
evaluate them in the order they are parsed according to the grammar- that i=
s, left-associative expressions are parsed left-associative, function argum=
ents from left to right, assignments right to left.</div></blockquote><div>=
<br>A bit different: I'd like default function arguments to be able to refe=
r to other function arguments. This is related in that it would force a seq=
uencing at least between the evaluation of the default argument and the eva=
luation of those arguments it references. In this particular case, there is=
 no performance to lose. And it can be seen as a first step into sequencing=
 more strictly.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_29_842034.1355067987979--

.