in reply to Prefix and postfix increment/decrement operator query

From perlop:

Note that just as in C, Perl doesn't define when the variable is incremented or decremented. You just know it will be done sometime before or after the value is returned. This also means that modifying a variable twice in the same statement will lead to undefined behaviour. Avoid statements like:

$i = $i ++; print ++ $i + $i ++;

Perl will not guarantee what the result of the above statements is.

"Undefined behaviour" means "anything could happen".

--

See the Copyright notice on my home node.

Perl training courses

Replies are listed 'Best First'.
Re^2: Prefix and postfix increment/decrement operator query
by Marshall (Canon) on Jul 03, 2009 at 01:53 UTC
    This explanation is very close. 'C' is very well defined about what is does in terms of statements with lvalues. 'C' is also explicitly ambiguous about what it does with subroutine parameters - in subroutine call, there is NO defined order of evaluation of expressions in the sub call: sub a(expr1, expr2)! C can do expr1 first or expr2 first. Often in C expr2 will be done first because that is the first value that will be pushed onto the calling stack. But there is nothing that mandates that or prohibits a different order. I seem to remember from a discussion with a higher Monk (Ikegami) that Perl always goes left to right, even in a sub arg evaluation, but I also seem to remember that this is not guaranteed by the language spec and therefore I wouldn't count on it.

    I have to mention that $i=$i++ or in C i=i++ is nonsensical. "i" gets assigned back to "i" and then "i" gets incremented and that value is "thrown away".

    In my opinion, a lexically scoped $var is a very cheap thing and should be used if there is any doubt about some subsequent statement. I'm not advocating creating extra unnecessary vars, just ones that "add clarity".

      In my opinion, a lexically scoped $var is a very cheap thing and should be used if there is any doubt about some subsequent statement. I'm not advocating creating extra unnecessary vars, just ones that "add clarity".

      I agree with you. I had posted this query because I thought about the expression behaving in a certain manner but it didn't. So it was pure curiosity. Thanks for that addition. I too wouldn't use such ambiguity in my work.