On Thu, Apr 25, 2002 at 12:51:33PM -0500, Craig S. Cottingham wrote: > On Thursday, April 25, 2002, at 10:51 , Bill -Sx- Jones wrote: > > >I would hope (wrongly again probably) that NOTHING would > >change; it would > >be: > > > > a = 1; > > > > --a = 0 + a++ = 1 == 1 > > > >Which means that --a + a++ = what a was to start with. > > You're making assumptions about order of evaluation, not only WRT > which side of the '+' binary operator is evaluated first, but also > whether the predecrement is performed before any other evaluation in > the expression, and whether the postincrement is performed after all > other evaluation in the expression.
[ snip ] > Unfortunately, I don't think the expression will evaluate to 1 > for any conforming implementation. Might I suggest that anyone who really wants to understand this google for "sequence point". Any program containing that expression is undefined and the compiler is free to do with it as it will. > But enough about C. What does perl do? In Perl the behviour is also undefined. Simon Cozens had a patch to make the behaviour more defined but it was never applied. One reason was that it reduced the opportunities for optimisation. Do not rely on undefined behaviour. That's probably more important in C than in Perl, but Perl will probably bite you someday too. [ snip ] > B and F make sense, if you assume that B is commuted to F > internally. C and E make sense, if you assume that E is commuted > to C internally. I can't figure out why A and D evaluate > differently, nor why A evaluates to 1 instead of 0 as I'd > expect. The results of C, D, and F suggest that perl, at least > in this instance, evaluates the operands to the '+' binary > operator in left-to-right order. Well, it has to do it some way or another :-) Fortunately, the source is available ... -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
