Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Operator evaluation order (http://www.velocityreviews.com/forums/t748149-operator-evaluation-order.html)

boltar2003@boltar.world 05-12-2011 10:06 AM

Operator evaluation order
 
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 05-12-2011 10:07 AM

Re: Operator evaluation order
 
On Thu, 12 May 2011 10:06:32 +0000 (UTC)
boltar2003@boltar.world 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 05-12-2011 10:21 AM

Re: Operator evaluation order
 
On 12 mai, 12:06, boltar2...@boltar.world 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 05-12-2011 10:24 AM

Re: Operator evaluation order
 
On Thu, 12 May 2011 03:21:07 -0700 (PDT)
Michael Doubez <michael.doubez@free.fr> wrote:
>On 12 mai, 12:06, boltar2...@boltar.world 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 05-12-2011 10:29 AM

Re: Operator evaluation order
 
On 2011-5-12 18:24, boltar2003@boltar.world 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 05-12-2011 11:11 AM

Re: Operator evaluation order
 
On Thu, 12 May 2011 18:29:28 +0800
Qi <no@no.no> wrote:
>On 2011-5-12 18:24, boltar2003@boltar.world 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 05-12-2011 11:47 AM

Re: Operator evaluation order
 
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 05-12-2011 11:48 AM

Re: Operator evaluation order
 
On 5/12/2011 6:24 AM, boltar2003@boltar.world wrote:
> On Thu, 12 May 2011 03:21:07 -0700 (PDT)
> Michael Doubez<michael.doubez@free.fr> wrote:
>> On 12 mai, 12:06, boltar2...@boltar.world 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
--
I do not respond to top-posted replies, please don't ask

Victor Bazarov 05-12-2011 11:56 AM

Re: Operator evaluation order
 
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
--
I do not respond to top-posted replies, please don't ask

Michael Doubez 05-12-2011 01:25 PM

Re: Operator evaluation order
 
On 12 mai, 12:24, boltar2...@boltar.world wrote:
> On Thu, 12 May 2011 03:21:07 -0700 (PDT)
>
>
>
>
>
>
>
>
>
> Michael Doubez <michael.dou...@free.fr> wrote:
> >On 12 mai, 12:06, boltar2...@boltar.world 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


All times are GMT. The time now is 05:19 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.