C history question

[Richard O'Keefe]

In article <174 at cpsolv.UUCP>, rhg at cpsolv.UUCP (Richard H. Gumpertz) writes:
> 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.

This is not entirely true.  For example, C inherited ++ and -- from B,
which ran on a machine which didn't have auto-{in,de}crement.  C and B
both inherited their set of test&branch operations from BCPL, which was
an implementation language for word-addressed machines (not even 360s!).
BCPL had test&branch versions of AND and OR, but no test&branch version
of XOR.  There are quite a lot of cheap hardware instructions which C
doesn't reflect at all (Rubin's complaint): e.g. PDP-11s have rotate
instructions, but C has no "rotate" operator.  Subscripts are a
seemingly simple operator, but can involve shifts and multiplies which
can be quite hairy, and floating-point arithmetic can hide very
expensive operations 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?

If you really don't want side-effects in X to be repeated,
	#define NegateVar(X) ((X) *= -1)
	#define ComplementVar(X) ((X) ^= -1)
and then
	NegateVar(fred);	/* has effect of fred = -fred; */
	ComplementVar(jim);	/* has effect of fred = ~fred; */
This is not hard.