-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday, April 25, 2002, at 10:51 , Bill -Sx- Jones wrote:
> I would hope (wrongly again probably) that NOTHING would
> change; it would
> be:
>
> a = 1;
>
> --a = 0 + a++ = 1 == 1
>
> Which means that --a + a++ = what a was to start with.
You're making assumptions about order of evaluation, not only
WRT which side of the '+'
binary operator is evaluated first, but also whether the
predecrement is performed before any other evaluation in the
expression, and whether the postincrement is performed after all
other evaluation in the expression.
My copy of Harbison & Steele's "C: A Reference Manual" (3rd
edition, 1991) says (p.207):
"In general, the compiler can rearrange the order in which an
expression is evaluated. The rearrangement may consist of
evaluating only the arguments of a function call, or the two
operands of a binary operator, in some particular order other
than the obvious left-to-right order."
It goes on to say (p.208):
"When evaluating the actual arguments in a function call, the
order in which the arguments and the function expression are
evaluated is not specified; but the program should behave as if
it chose one argument, evaluated it fully, then chose another
argument, evaluated it fully, and so on, until all arguments
were evaluated. (A similar restriction holds for each operand to
a binary expression operator.)"
That suggests that half of your assumption was correct: the
predecrement and postincrement of "a" should take place at the
time the variable is evaluated, prior to applying the '+' binary
operator.
So, one possible order of evaluation is:
a = 1;
(--a => 0) + (a++ => 0) => 0, with a => 1 after evaluation
because "a++" takes the value of "a", *then* increments it.
Another order of evaluation is possible, if the compiler chooses
to commute the operands to the '+' binary operator:
a = 1;
(a++ => 1) + (--a => 1) => 2, with a => 1 after evaluation
Unfortunately, I don't think the expression will evaluate to 1
for any conforming implementation.
But enough about C. What does perl do?
A: craigc@samantha craigc $ perl -e '$a = 1; print +(--$a +
$a++) . "\t$a\n"'
1 1
B: craigc@samantha craigc $ perl -e '$a = 1; print +($a +
$a++) . "\t$a\n"'
3 2
C: craigc@samantha craigc $ perl -e '$a = 1; print +(--$a +
$a) . "\t$a\n"'
0 0
D: craigc@samantha craigc $ perl -e '$a = 1; print +($a++ +
- --$a) . "\t$a\n"'
2 1
E: craigc@samantha craigc $ perl -e '$a = 1; print +($a +
- --$a) . "\t$a\n"'
0 0
F: craigc@samantha craigc $ perl -e '$a = 1; print +($a++ +
$a) . "\t$a\n"'
3 2
B and F make sense, if you assume that B is commuted to F
internally. C and E make sense, if you assume that E is commuted
to C internally. I can't figure out why A and D evaluate
differently, nor why A evaluates to 1 instead of 0 as I'd
expect. The results of C, D, and F suggest that perl, at least
in this instance, evaluates the operands to the '+' binary
operator in left-to-right order.
Oh, in case it matters:
craigc@samantha craigc $ perl -v
This is perl, v5.6.1 built for darwin
- --
Craig S. Cottingham
[EMAIL PROTECTED]
PGP key available from:
<http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0xA2FFBE41>
ID=0xA2FFBE41, fingerprint=6AA8 2E28 2404 8A95 B8FC 7EFC 136F
0CEF A2FF BE41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org
iD8DBQE8yEIsE28M76L/vkERAg1/AKD7Sk5P/MadAkqs3jl1ozbhw7RBaQCbB5no
oZo4yyEQBvyeGoVxLrq+EIk=
=kFmj
-----END PGP SIGNATURE-----
