Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: New Features:  ++(expr)
Summary: ++lvalue not redundant
Keywords: lvalue expression
Message-ID: <648@cresswell.quintus.UUCP>
Date: 14 Feb 88 07:40:50 GMT
References: <386@osupyr.UUCP> <1102@bc-cis.UUCP> <681@devon.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 33

In article <681@devon.UUCP>, paul@devon.UUCP (Paul Sutcliffe Jr.) writes:
> In article <1102@bc-cis.UUCP> john@bc-cis.UUCP (John L. Wynstra) writes:
> > In article <386@osupyr.UUCP> ddc@osupyr.UUCP (Don Comeau) writes:
> > > I think ++expr should be an expression which has the value expr+1
> > 	Yes, can you say redundant?
> Sure, ++expression is redundant.  So is ++lvalue.  If you dispise the
> redundancy, why have ++ and -- at all, since I can easily use
> 	lvalue = lvalue + 1
>or 	lvalue += 1

There is an important difference between
	lvalue = lvalue+1;
and	lvalue += 1;
The difference is that the lvalue is evaluated twice in the former,
and only once in the latter.  Consider
	*x++ = *x++ + 1;
-vs-	*x++ += 1;
Prefix ++ and -- are redundant, because they can be simulated
exactly using +=, but postfix ++ and -- aren't.  (Strictly speaking,
to be consistent with the other assignment operators, shouldn't the
simple assignment operator in C be ",="?  Just kidding...)

The really horrible thing about the suggestion is that if ++(expr)
meant the same as (expr)+1 except for lvalues, we'd have
	++(x)		increments x, but
	++(x+0)		wouldn't.
I have seen too many bugs materialise in otherwise sensible
programs due to the "feature" of Fortran and PL/I that in
passing arguments to a procedure
	x		means pass the address of x, but
	(x)		means pass the address of a copy of x.
C has enough crannies for bugs to breed in without giving them
some more.