Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: C history question
Keywords: C design
Message-ID: <11046@smoke.BRL.MIL>
Date: 13 Sep 89 08:03:59 GMT
References: <575@calmasd.Prime.COM> <1687@sunset.MATH.UCLA.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 14

In article <1687@sunset.MATH.UCLA.EDU> pmontgom@math.ucla.edu (Peter Montgomery) writes:
>shouldn't we be allowed to abbreviate this to
>		allok &&= a[i] > b[i];

If allok is being used as a Boolean, as it should be in such a context,
you can use &= instead.  One less character to type, too.

Now I suppose someone will point out that == does the wrong thing for
the high-order 0 bits in a C pseudo-Boolean (represented as int 0 or 1),
so they "need" an === assignment-operator.  This can clearly quickly get
out of hand.  Suffice it to say that the lack of the full set of 10
non-trivial binary Boolean operators and their corresponding assignment
versions hasn't seemed to be a significant practical problem to me, and
I'm more "Boolean aware" than most..