You have to understand how expressions evaluate. The pre- and post-increment (and decrement) operators change the variables value, but the variable plus the operator constitute and expression who's value varies depending upon the placement of the ++. Essentially, the value of the expression $i++ is original value of $i and $i is incremented by 1. The value of the expression ++$i is new value of $i after $i is incremented by 1.

$i = ++$i + $i++;
[download]

In the above example, we evaluate the expression right to left. The expression, $i++, evaluates as zero, even though $i is now 1. The second expression, ++$i, evaluates as 2 (since $i is now 1) and 2+1 equals 3.

$i = $i++ + ++$i;
[download]

Pretty straightforward now. The rightmost ++$i evaluates as 1 and $i is set to one. The $i++ also evaluates to 1 (remember, with a post-increment operator doesn't change the return value of the expression, just the variable -- confused yet? :). So, 1 + 1 equals two.

Cheers,
Ovid

Update: Got the concept right, but I evaluated in reverse order. Whoops! Juerd is right.

Update2: Okay, I'm smoking crack. If things are evaluated left to right, then the following is true:

$ perl -e 'print 1-3+2'
0
[download]

Well, it turns out that this is true. If it were evaluated right to left, then the answer would negative four. What I think is going on (though I can't prove it offhand) is that built-in unary operators are evaluated right to left, and then the rest of the expression is evaluated based upon precedence rules, if any. Anyone want to shed light on this?

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

In the above example, we evaluate the expression right to left.

Is that always, or just in this case? When are expressions evaluated left-to-right, and when right-to-left? And why is that so? I would have thought that do { $i = 0; ++$i + $i++; } would evaluate to 2 because (0 + 1) + 1 == 2, but apparently, I'm wrong.

Update: Got the concept right, but I evaluated in reverse order. Whoops! Juerd is right.

Answer to Ovid's update: No, I'm not, as do { $i = 0; ++$i + $i++ } does NOT equal 2 -- the right-to-left apparently is correct, I'm just wondering why it is that way.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

If it were evaluated right to left, then the answer would negative four

No, it's a per-operator thing, as + and - are different operators, and their precedence defines they should be evaluated left-to-right. This is done by implicit parentheses:

2;0 juerd@ouranos:~$ perl -MO=Deparse,-p -e'sub one { 1 } sub two { 2 
+} sub three { 3 } print one() - three() + two()'
sub one {
    1;
}
sub two {
    2;
}
sub three {
    3;
}
print(((one() - three()) + two()));
[download]

(I had to use these subs, because Perl optimizes 1-2+3 to a literal 0 :)

So we have these calculation:
1. 1 - 3 = -2
2. answer ( = -2 ) + 2 = 0
But which are evaluated first? the 1 or the 3? The -2 or the 2? It becomes clear when you test the operators one by one (or so I thought):

2;0 juerd@ouranos:~$ perl -le'sub foo { print "foo"; return 1 } sub ba
+r { print "bar"; return 2 } print foo + bar'
bar
foo
1
2;0 juerd@ouranos:~$ perl -le'sub foo { print "foo"; return 1 } sub ba
+r { print "bar"; return 2 } print foo && bar'
foo
bar
2
[download]

So I decided to test a lot of operator this way, but found out that everything was evaluated left-to-right, but not if I left out the parens. Why did my first test print bar before foo then? Because I didn't print foo() + bar() but did print foo( +bar() ).

So that still doesn't solve our mistery...

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

Ovid offers a plausible explanation for the behavior. However, relying on specific results from such expressions is a very bad idea. Subtle changes to Perl could easily change the results and break any programs that depend on them. Most Perl developers would consider a program that depends on the results of such expressions to already be broken.

Expression        Perl  GCC
----------------------------
x = ++x           1     1
x = x++           0     1
x = x++ + x++     1     1
x = x++ + ++x     2     3
x = ++x + x++     3     3
x += x++          1     1
x -= ++x          0     0
[download]

Hi,
the problem is that, basically, this kind of expression does not make sense nor it has a natural value. Post- and pre-increment are special case of the so-called side-effect expression, i.e. expression whose evaluation changes somehow the value of the variables involved.

Now, in C it is said plainly that you must not rely on the order of evaluation of the sub expressions. I remember an example running on an old machine in which the same expression (with side effects) gave a different result when compiled with the native compiler and when compiled with gcc.

IIRC, with perl is the same thing, because the optimizer is allowed to change the order in which your sub expressions are evaluated (except of course when the operator is one of the short-cut ones).

So, never forget the simple rule:

Never, ever, put more than one side-effect expression affecting the same variable into one expression.

I ran the following code:

$i = $i++;
print "Test 1: $i\n";

$i = 0;
$i = 0 + $i++; $i = ++$i + $i++;
print "Test 2: $i\n";

$i = 0;
$i = ++$i + $i++;
print "Test 3: $i\n";

$i = 0;
$i = $i++ + ++$i;
print "Test 4: $i\n";
[download]

Test 1: 0
Test 2: 3
Test 3: 3
Test 4: 2
[download]

So if you thought your output was weird maybe this has something to do with it.

UPDATE: I was going through my posts and found this one. The final incrementation I mention I believe is ultimately irrelevant since the expression's return value i assigned to $i thereby over-writing the value $i has after the ++ operator.

--
$you = new YOU;
honk() if $you->love(perl)

array[i++] = array[i++] + i;
[download]

What would the perl equivalent do? I guess it would be consistent across platforms, since perl evaluates expressions in the same order on all platforms.

To expand on tye: What gcc does for "i=i++;" is conforming behaviour for ISO C. What any implementation does for it is conforming!

This sort of code (technically, modifying a variable more than once between sequence points) is specifically said by the standard to evoke undefined behaviour (see the comp.lang.c FAQ). In the comp.lang.c.* newsfroups, it is said that the compiler could compile code which causes daemons to fly out of your nose (aka nasal daemons)! It could also choose to reformat your hard disks except on Friday the 13th, return the value 17, or do anything else.

Is this "broken"? Not really. By not specifying evaluation order more precisely, the standard allows the compiler a lot more latitude in compiling efficient code. This, at the price of disallowing some essentially useless code. (Would you be happier if the standard said "i=i++; is guaranteed to set the value of i to -29"? Would you use it?)

Note that all this applies to code generation, not to parsing. That "i++ - ++i + i" is parsed as "(i++ - ++i) + i" has nothing to do with the code emitted by the compiler. Parsing has no idea of "the same" object; that is part of the semantics of C, not its syntax. But not everything illegal is a syntax error!

Perl has not had such a rigourous standardization. Furthermore, only one implementation exists at any time (assuming we decide 5.004, 5.005, 5.00503, 5.6.0, 5.6.1, and the rest are all different). So it is very tempting to apply the "test and see" engineering technique.

I'd join tye in recommending you avoid this. First, because it isn't documented behaviour. Unfortunately, Perl has loads of behaviour that couldn't really be said to be "documented" and still gets used. The thing is, these other properties are actually useful. The syntax for them evokes a specific interpretation. Can you really give a good argument for compiling "(++A)+(B++)" (legal code, if A and B are different objects) as any of the following codes, rather than any of the others?

1. LOAD R1, A
   INCR R1
   LOAD R2, B
   ADD  R3, R1, R2
   INCR R2
   STORE A, R1
   STORE B, R2
   [download]

2. LOAD R1, A
   INCR R1
   STORE A, R1
   LOAD R2, B
   ADD R3, R1, R2
   INCR R2
   STORE B, R2
   [download]

Hi, thanks for the extensive reply. It was just what I was after. I am fully aware that this is code that shouldn't be used, I was just curious why it differed as addition shouldn't care about left/right side.
/jon

What i think is happening is this: the reference to the variable $i is being modified by the auto-(in|de)crement operators before the addition operation because of the precedence table. The reference then gets updated for the left $i for a right-side auto-increment because we're dealing with a reference to the actual variable, not a hard-coded number -- and in the case of the post-increment, because of a bug.

Examples:
Let's say we have the expression

$a + ++$a
[download]

0 + $a++
[download]

$a + $a++
[download]

So, to explain the strange ++$a + $a++ i think it works like this:

1. the code is parsed, the ++'s get the precedence to go first
2. addition being a left-wise operator, ++$a gets evaluated first; $a gets ++'d to 1
3. $a++ generates a post-decrement after the statement is over and increments the left-side (erroneously)
4. the values (2 + 1?) are added returning 3
5. the post-decrement code is run, and $a is now 2

i could be wrong :/

Here's what i ran with the results i obtained:

#!/usr/bin/perl -w
use strict;

for $b (
    '$a++       ',
    '0    + $a++',
    '0    + ++$a',
    '++$a + $a',
    '$a   + ++$a',
    '$a   + $a++',
    '++$a + $a++',
    '$a++ + ++$a',
    '$a+=$a++'
) {
  $a = 0;
  print "$b\t=", eval($b), "\t\$a= $a\n";
}
__END__
# results:
$a++           =0    $a= 1
0    + $a++    =0    $a= 1
0    + ++$a    =1    $a= 1
++$a + $a    =2    $a= 1
$a   + ++$a    =2    $a= 1
$a   + $a++    =1    $a= 1
++$a + $a++    =3    $a= 2
$a++ + ++$a    =2    $a= 2
$a+=$a++    =1    $a= 1
[download]

hope this helps,
jynx

update: Hmmm, even stranger.

If we take

$a + $a + $a++ # = 0 (correct)
$a + $a + ++$a # = 1 (correct)
$a + $a++ + $a # = 2 (the trailing $a has no effect maybe?)
$a + ++$a + $a # = 3 (the ++ effects previous $a as before?)
[download]

So the first addition is probably becoming zero before the second addition is messing it up? And to further confuse things:

$a + $a + ++$a + $a++ # = 2 (correct!)
0 + ++$a + $a++ # = 3 (d'oh!)
[download]

1. $X is 0
2. ++$X increments $X's value, and returns the variable $X (not its value)
3. $X++ return's $X's value and then increments it, meaning $X is now 2
4. 2 + 1 = 3

perl -de0
main::(-e:1):   0
  DB<1> x $N = 0; ++$N, $N++
0  2
1  1
[download]

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker, who'd like a (from-home) job
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

Right. The ultimate reason is that perl does everything by reference internally, not by value. We don't deal with real numbers or strings, we deal with pointers to perl variables. Since you're reusing those pointers multiple times, and affecting them multiple times as well, it's up in the air what the ultimate value will be. (Depends on how perl builds and evaluates the expression)