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