in reply to Operator Associative in Perl

there is no associative for '++' and '--' operator

There are two major mistakes there.

While Perl doesn't document its operand evaluation order, it always evaluates operands from left to right for left-associative operators and exponentiation (**), and from right to left for assignments operators.

This case is no exception. There are two characteristics (features?) of Perl that cause the result you observe:

So, that means

is basically equivalent to
do { local @_; alias $_[0] = "%d%d%d%d%d\n"; alias $_[1] = $a++; # Returns new value 5, $a=6 alias $_[2] = $a--; # Returns new value 6, $a=5 alias $_[3] = ++$a; # Returns $a (lvalue) $a=6 alias $_[4] = --$a; # Returns $a (lvalue) $a=5 alias $_[5] = $a; # Returns $a (lvalue) $a=5 \&printf; }
When printf gets the values from @_, it sees

When I run the same program in C, I got, 45555. Please explain how it is working?

C leaves the operand evaluation order up to the compiler. Results will vary from compiler to compiler. It looks like yours passed by reference, evaluating from right to left.

Replies are listed 'Best First'.
pre and post increment of subroutine arguments
by ig (Vicar) on Jun 04, 2009 at 21:37 UTC

    I find the difference between $a++ and ++$a as subroutine arguments to be quite interesting/surprising.

    In a subroutine the elements of @_ are usually aliases to the arguments of the subroutine call, allowing the subroutine to modify the caller's variables.

    In the case of ++$a, the corresponding element of @_ is a reference to the same IV as $a but in the case of $a++ it is a reference to a new IV, effectively preventing the subroutine from modifying the caller's variable. In both cases the array element is an lvalue (i.e. it can be modified), but only in the case of pre-increment can the subroutine modify the caller's variable.

    Using pre/post increment/decrement on an argument to a subroutine that attempts to modify that argument is not a good thing to do because the order of execution is not defined. None the less, the difference in implementation is interesting.