C history question
Richard H. Gumpertz
rhg at cpsolv.UUCP
Sat Sep 16 00:34:56 AEST 1989
The && and || operators differ from the & and | operators in two respects:
1) they do NOT perform bitwise operations; 4 && 2 is 1 while 4 & 2 is 0.
2) they are guaranteed to perform short-circuited evalauations: the
right-hand operand will NOT be evaluated if the left-hand operand
determines the value of the expression.
An ^^ operator would maintain the first property of not being bitwise which
would be usesful for non 0/1 booleans; on the other hand no short-circuit
evaluation is possible with XOR because BOTH operands must always be evaluated.
&& and || also have straightfoward implementations in control-flow (e.g. inside
an IF) contexts; ^^ is not as straightforward in most architectures. Most
compilers would have to implement X ^^ Y as (X != 0) ^ (Y != 0) or as
X ? (Y == 0) : (Y != 0) or such.
Might the lack of short-circuiting and the lack of any code advantage over the
equivalents given above caused K&R to decide the ^^ operator was not worthwhile?
As for &&=, ||=, and ^^=, might the lack of trivial implementation (few
if any architectures directly implement the non-bitwise booleans; only flow-
contexts allow "better" code to be produced for && and ||; &&= and ||= are
by definition not flow contexts!) have affected K&R similarly? They might
have reasoned that X = (X != 0) & (Y != 0) or X = (X != 0) && (Y != 0) will
generate code as good as X &&= Y and so left them out.
I hate resorting to implementation arguments when discussing the design of a
language, but after all C does very much reflect its history as an
implementation language with few "expensive-to-implement" operations hidden
behind seemingly simple operators.
As long as we are discussing missing "assignment" operators, you might ponder
the lack of unary assignment operators. Why should I have to say X = -X or
X = ~X? Why not have unary assignment operators (ala ++ and --) for negation
and complement? I suppose a new syntax would have to be invented, but it might
be useful at times. Remember that mentioning X only once guarantees that its
side-effects, if any, will happen only once!
Maybe K or R would care to chime in?
Richard H. Gumpertz (913) 642-1777
...uunet!amgraf!cpsolv!rhg
More information about the Comp.lang.c
mailing list