Re^2: Why does the first $c evaluate to the incremented value in [$c, $c += $

in reply to Re: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ?
in thread Why does the first $c evaluate to the incremented value in [$c, $c += $_] ?

Well, but what about this? It does not look like your third example worked...

$ perl -wlE 'my $x=1; my @A=($x, $x++); say join $/, @A;'
2
1
[download]

Comment on Re^2: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ? Download Code

Replies are listed 'Best First'.
Re^3: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ? by Eily (Monsignor) on Mar 04, 2014 at 21:34 UTC
I believe this falls into the undefined behaviour of auto increment operator : 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 behavior. So because of the precedence list, you know the right part will be run first, and the left part after that, but when exactly the variable will be incremented is left to Perl's implementation.	[reply]
Re^4: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ? by Laurent_R (Canon) on Mar 04, 2014 at 22:17 UTC
Yes, you are right. In C, if you write: `c = c++;` [download] the behavior is not defined by the C standard. Which does not mean that the compiler will return an undefined value. Just the implementer of the compiler is free to do whatever she or he wants. And I remember very well having tried it about 16 years ago with GCC under Linux and another compiler under Windows and having obtained the original value of c for one of them and the incremented value of c for the other (although I do not remember which one gave what). For this type of things, the Perl syntax is rooted in C, but, in a certain way, the behavior is not imposed by a standard which may be silent about certain edge cases, but is sort of defined by the Perl compiler itself. The Perl compiler gives the logical result that I would expect (although what the logical result should be might be considered debatable): `my $c = 2; $c = $c ++ ; # $c is now 2 $c = ++$c ; # $c is now 3` [download] And it seems to me that using $c and $c+=1 in the same expression falls into the same category as using $c and $c++ (or ++c) in the same expression, something not very well defined, which is why I also brought those additional examples. Your explanation using operator precedence does make sense (I had not seen it when I posted my examples), but it might simply just be one of those not well-defined behavior cases.	[reply] [d/l] [select]
Re^5: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ? by Eily (Monsignor) on Mar 04, 2014 at 23:04 UTC
I may be mistaken, but I'm think that `$c+=1` is actually defined to run the two steps one right after the other, while what is ambiguous in `$c++` is the fact that $c will be incremented later. I do agree on the fact that undefined behaviour does not mean undefined value, that's why it's hard to track.	[reply] [d/l] [select]
Re^3: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ? by Laurent_R (Canon) on Mar 04, 2014 at 21:34 UTC
Sorry, you are right, I originally made a mistake when copying the values, my third example gives (3, 2), not (2, 3) as I originally typed by mistake. I almost immediately corrected it, but it appears you had time to see it before I corrected my error, even though I corrected within 2 minutes of the original post.	[reply]

In Section Seekers of Perl Wisdom