From: "Matthew Byng-Maddick" <[EMAIL PROTECTED]>
> Instinct suggests that because the increment must bind tighter than the
> assignment it gets evaluated first, and therefore the value assigned to a
> *should* be the return value from (a++) which is, in this case, 1.
>
> > % gcc -o try try.c ; ./try
> > 3
>
> I believe that this is incorrect based on this, but then have a go at
trying
> to predict argument order in functions in gcc, you may be surprised. :-)
In the C I was taught, the result I would have expected would be 3. In long
hand the statements would read:
int a=2;
a=a;
a++;
Thus the result is 3. If the compiler doesn't expand it to that then, that I
guess that's a feature in the compiler. The postincrement operator
evaluation is supposed to take place after the current statement has been
evaluated, regardless of whether it's on the rhs or lhs.
> > % perl try.pl
> > 2
>
> This seems more sensible behaviour to me.
This surpises me, I would have expected it to follow the C pattern above.
Barbie.
