Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: C history question
Keywords: C design, XOR
Message-ID: <29557@news.Think.COM>
Date: 15 Sep 89 19:32:12 GMT
References: <10390@phoenix.Princeton.EDU>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 38

Regarding the lack of the ability to abbreviate

	allok = allok && (a[i] > b[i])
with
	allok &&= a[i] > b[i]

In article <10390@phoenix.Princeton.EDU> tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis) writes:
>Why not
>	       allok &= (a[i] > b[i]);
>In this case, the expression on the right will evaluate to either 0
>or 1, and you can AND this with the previous value of allok.

That's not a good substitute, for two reasons.

First, because && and !! treat all non-zero values as boolean truth,
but & does bit-wise AND.  If allok contained 2 before the above
expression it would end up with 0 (whether or not the comparison is
true or false!).  I admit that such code is not a good idea, and your
version may actually work in the poster's case.

Second, and more importantly, is that your version doesn't retain the
short-circuit operation.  If the expression were something like

	allok = allok && a[i++] > b[j++]

then the side effects on i and j would be different from

	allok &= a[i++] > b[j++]

The first must NOT increment i and j when allok is true, while the
second MUST increment them in any case.


Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar