Velocity Reviews > C++ > Operator evaluation order

Operator evaluation order

boltar2003@boltar.world
Guest
Posts: n/a

 05-12-2011
Perhaps this is a stupid question, but can someone explain why the
operator evaluation order differs for assignment compared to mathematic
operators when there is only a single operator type in the expression?

Eg:

a1 = a2 = a3 = a4 will evaluate as a3=a4, a2=a3, a1=a2

but

a1 + a2 + a3 + a4 will evaluate as a1=a2, a1=a3, a1=a4

Why the difference?

B2003

boltar2003@boltar.world
Guest
Posts: n/a

 05-12-2011
On Thu, 12 May 2011 10:06:32 +0000 (UTC)
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>a1 + a2 + a3 + a4 will evaluate as a1=a2, a1=a3, a1=a4

Sorry , that should have read a1+a2, a1+a3, a1+a4

B2003

Michael Doubez
Guest
Posts: n/a

 05-12-2011
On 12 mai, 12:06, (E-Mail Removed) wrote:
> Perhaps this is a stupid question, but can someone explain why the
> operator evaluation order differs for assignment compared to mathematic
> operators when there is only a single operator type in the expression?
>
> Eg:
>
> a1 = a2 = a3 = a4 will evaluate as a3=a4, a2=a3, a1=a2
>
> but
>
> a1 + a2 + a3 + a4 will evaluate as a1+a2, a1+a3, a1+a4
>
> Why the difference?

Because the standard says that = operator groups right-to-left
(§5.17/1) while + operator groups left-to-right (§5.7/1).

--
Michael

boltar2003@boltar.world
Guest
Posts: n/a

 05-12-2011
On Thu, 12 May 2011 03:21:07 -0700 (PDT)
Michael Doubez <(E-Mail Removed)> wrote:
>On 12 mai, 12:06, (E-Mail Removed) wrote:
>> Perhaps this is a stupid question, but can someone explain why the
>> operator evaluation order differs for assignment compared to mathematic
>> operators when there is only a single operator type in the expression?
>>
>> Eg:
>>
>> a1 =3D a2 =3D a3 =3D a4 will evaluate as a3=3Da4, a2=3Da3, a1=3Da2
>>
>> but
>>
>> a1 + a2 + a3 + a4 will evaluate as a1+a2, a1+a3, a1+a4
>>
>> Why the difference?

>
>Because the standard says that =3D operator groups right-to-left
>(=A75.17/1) while + operator groups left-to-right (=A75.7/1).

Fair enough. Do you know why assignment doesn't group left to right too?

B2003

Qi
Guest
Posts: n/a

 05-12-2011
On 2011-5-12 18:24, (E-Mail Removed) wrote:
>
> Fair enough. Do you know why assignment doesn't group left to right too?

Then you have to write "5 = n" to assign 5 to n.

--
WQ

boltar2003@boltar.world
Guest
Posts: n/a

 05-12-2011
On Thu, 12 May 2011 18:29:28 +0800
Qi <(E-Mail Removed)> wrote:
>On 2011-5-12 18:24, (E-Mail Removed) wrote:
>>
>> Fair enough. Do you know why assignment doesn't group left to right too?

>
>Then you have to write "5 = n" to assign 5 to n.

No you wouldn't. You're confusing the grouping order with left hand side and
right hand side in the actual expression.

B2003

Nobody
Guest
Posts: n/a

 05-12-2011
On Thu, 12 May 2011 10:24:09 +0000, boltar2003 wrote:

> Fair enough. Do you know why assignment doesn't group left to right too?

Because the LHS of an assignment must be an lvalue (roughly, something
which has associated storage: a variable, a structure field, the result of
dereferencing a pointer with * or [], etc).

If "=" was left-associative, the expression:

a1 = a2 = a3 = a4

would be equivalent to:

((a1 = a2) = a3) = a4

But "(a1 = a2) = a3" makes no more sense than "(1 + 2) = a3".

OTOH, the expression:

a1 = (a2 = (a3 = a4))

doesn't have this problem, as the LHS is always an lvalue.

Victor Bazarov
Guest
Posts: n/a

 05-12-2011
On 5/12/2011 6:24 AM, (E-Mail Removed) wrote:
> On Thu, 12 May 2011 03:21:07 -0700 (PDT)
> Michael Doubez<(E-Mail Removed)> wrote:
>> On 12 mai, 12:06, (E-Mail Removed) wrote:
>>> Perhaps this is a stupid question, but can someone explain why the
>>> operator evaluation order differs for assignment compared to mathematic
>>> operators when there is only a single operator type in the expression?
>>>
>>> Eg:
>>>
>>> a1 =3D a2 =3D a3 =3D a4 will evaluate as a3=3Da4, a2=3Da3, a1=3Da2
>>>
>>> but
>>>
>>> a1 + a2 + a3 + a4 will evaluate as a1+a2, a1+a3, a1+a4
>>>
>>> Why the difference?

>>
>> Because the standard says that =3D operator groups right-to-left
>> (=A75.17/1) while + operator groups left-to-right (=A75.7/1).

>
> Fair enough. Do you know why assignment doesn't group left to right too?

<shrug> Seems rather logical to conclude that

a = b = c = 5;

actually means "all values become 5" instead of "'a' becomes the same as
'b', then the same as 'c', then 5", since the latter sequence (which is
what it would be if assignment grouped left to right) doesn't change the
values of 'b' and 'c' and changes 'a' thrice (which seems rather
unnecessary).

V
--

Victor Bazarov
Guest
Posts: n/a

 05-12-2011
On 5/12/2011 7:47 AM, Nobody wrote:
> On Thu, 12 May 2011 10:24:09 +0000, boltar2003 wrote:
>
>> Fair enough. Do you know why assignment doesn't group left to right too?

>
> Because the LHS of an assignment must be an lvalue (roughly, something
> which has associated storage: a variable, a structure field, the result of
> dereferencing a pointer with * or [], etc).
>
> If "=" was left-associative, the expression:
>
> a1 = a2 = a3 = a4
>
> would be equivalent to:
>
> ((a1 = a2) = a3) = a4
>
> But "(a1 = a2) = a3" makes no more sense than "(1 + 2) = a3".

It makes *some* sense. You actually are allowed to write that (try it,
you might be surprised). Since assignment returns a reference, you can
keep assigning to it. The expression

(a1 = a2) = a3

is *logically* equivalent to (a1 = a2, a1 = a3), except for the sequence
point, which doesn't exist in the first expression, and thus gives the
first expression, while legitimate syntactically, undefined behavior
(unless I missed something).

>
> OTOH, the expression:
>
> a1 = (a2 = (a3 = a4))
>
> doesn't have this problem, as the LHS is always an lvalue.

The result of an assignment is an lvalue with built-in types and with
the compiler-provided assignment operator for classes. That's why you
can do

SomeClass a, b, c;
(a = b) = c;

without a problem since the assignment for classes is a function call
and as such provides an extra sequence point (unlike with built-in
types), so no undefined behavior there.

V
--

Michael Doubez
Guest
Posts: n/a

 05-12-2011
On 12 mai, 12:24, (E-Mail Removed) wrote:
> On Thu, 12 May 2011 03:21:07 -0700 (PDT)
>
>
>
>
>
>
>
>
>
> Michael Doubez <(E-Mail Removed)> wrote:
> >On 12 mai, 12:06, (E-Mail Removed) wrote:
> >> Perhaps this is a stupid question, but can someone explain why the
> >> operator evaluation order differs for assignment compared to mathematic
> >> operators when there is only a single operator type in the expression?

>
> >> Eg:

>
> >> a1 =3D a2 =3D a3 =3D a4 will evaluate as a3=3Da4, a2=3Da3, a1=3Da2

>
> >> but

>
> >> a1 + a2 + a3 + a4 will evaluate as a1+a2, a1+a3, a1+a4

>
> >> Why the difference?

>
> >Because the standard says that =3D operator groups right-to-left
> >(=A75.17/1) while + operator groups left-to-right (=A75.7/1).

>
> Fair enough. Do you know why assignment doesn't group left to right too?

I don't understand the others' answer. I would simply say that the
semantic intended from base type is that all variable get the same
value. But you only now it from the right most value, thus it makes
sense to have right grouping:
a1 = ( a2 = ( a3 = a4 ) );

Concerning the arithmetic operators, I guess it is because of
asymmetric operators such as '-' which group left in math notation: 9
- 3 - 2 != 9 - ( 3 - 2 ). In order to be coherent with mathematical
notation, asymmetric arithmetic operators group left and the same
convention was kept for symmetric ones.

--
Michael