Multiple assignments & side-effects
Blair P. Houghton
bhoughto at hopi.intel.com
Wed Mar 13 17:57:29 AEST 1991
In article <64846 at eerie.acsu.Buffalo.EDU> cloos at acsu.buffalo.edu (James H. Cloos) writes:
>Which ... is the best way...:
>OPTION 1: /* This is my guess, based on K&R2 p 21 */
>bar_p->eg=bar_p->ie=(++bar_p)->dH=0;
>OPTION 2:
>(++bar_p)->eg=bar_p->ie=bar_p->dH=0;
Neither.
If K&R2 shows such a thing, then it assumes, quite
wrongly, that the `++' is done before anything else.
>From the Assignment Operators section of the standard:
"The order of evaluation of the operands is unspecified."
(ANSI X3.159-1989, sec. 3.3.16, pp. 54, l. 17)
I.e., it can dereference any of the unincremented `bar_p's
before it performs the `++' on the incremented `bar_p'; or
not; or both. The `++' is only guaranteed to be done
before the incremented expression assumes the value of its
argument (and it's gone around here before that it only has
to _behave_ that way, not actually perform the machine code
in that exact order, e.g. it can generate `1 + bar_p++').
bar_p += 1;
bar_p->eg = bar_p->ie = bar_p->dH = 0;
is the correct way to do it.
(Irrelevant style note: when incrementing things I don't
need the value of immediately, I use `x += 1' instead of `x++'
or `++x'. An optimizer won't care, but ostensibly it doesn't
leave a value sitting in an abstract-machine's register, on
its stack, &c.)
--Blair
"postings += 1;"
More information about the Comp.lang.c
mailing list