🚀 go-pugleaf

In article <2076@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes:
>In article <353@cullvax.UUCP> drw@cullvax.UUCP (Dale Worley) writes:
>>> In article <760@oakhill.UUCP> tomc@oakhill.UUCP (Tom Cunningham) writes:
>>> >	/* a = b + b + b */
>>> >	a = ((b=1),b) + ((b=2),b) + ((b=3),b)
>>> >
>>> >I expected the result to be 6.  With the Microsoft C compiler and the
>>> >compiler on the Sun 3, the result is 9.
>>Dec VAX Ultrix gives 9.
>>Lattice C 3.00 for MS-DOS gives 7!!!  (Yes, that's "7", not a typo!)
>Microsoft C 3.0 small memory model gives 6 and DeSmet C 2.51 small
>memory model gives 7.
>
>Looks like this falls in the "don't count on the order of evaluation of
>subexpressions with side-effects" bucket, even though it doesn't look
>illegal.
>
>Certainly, anything that produces widely different answers under
>different popular implementations of C should be avoided; it is all well
>and good to try to say "such and so is RIGHT, and anything that does
>different is wrong" but that doesn't help portability.
>

Ok, this seems good advice for expressions where each subexression
_must_ be evaluated at _some_ time.
But, how about
	c = (b=1,a==1) || (b=2,a==0) || (b=3,a==3) || (b=4,a==2);
as a quick nice way of saying
	switch (a) {
	    case 1: b=1; c=1; break;
	    case 0: b=2; c=1; break;
	    case 3: b=3; c=1; break;
	    case 2: b=4; c=1; break;
	    default: c=0;
	}
where the evaluation will "break off" at the point where one of
the comparisons first succeeds.

(I actually wanted to use something a bit like this a few days ago,
but now I'm not too sure its that portable at all, considering
all the problems with "+").

Of course, compilers on which _this_ doesn't work should be
considered even *more* wrong than those as described above, but
that's not too constructive a complaint...


--
Simon Brown
Dept. of Computer Science, University of Edinburgh.
{seismo,ihnp4,decvax}!mcvax!ukc!cstvax(!its63b?)!simon