- **C++**
(*http://www.velocityreviews.com/forums/f39-c.html*)

- - **Operator evaluation order**
(*http://www.velocityreviews.com/forums/t748149-operator-evaluation-order.html*)

Operator evaluation orderPerhaps 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 |

Re: Operator evaluation orderOn 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 |

Re: Operator evaluation orderOn 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 |

Re: Operator evaluation orderOn 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 |

Re: Operator evaluation orderOn 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 |

Re: Operator evaluation orderOn 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 |

Re: Operator evaluation orderOn 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. |

Re: Operator evaluation orderOn 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 |

Re: Operator evaluation orderOn 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 |

Re: Operator evaluation orderOn 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.