[comp.lang.c] New Features: ++

ddc@osupyr.UUCP (Don Comeau) (02/08/88)

Since everyone else is suggesting their addtion to C, here is one I
think would be useful.  Why are ++ and -- still limited to lvalues?  I
think ++expresion should be an expression which has the value
expression+1.

Are there any good reason why this hasn't been done?

Yes, I do know my history.  ++ and -- were originally implemented via
machine instructions which played with memory.  That is fine, but it
doesn't explain why that limitation should be inherent in C itself.

( I guess expression++ could also be legal, but fairly useless! :-)

Flames welcome!  Maybe I'd learn something.

Don Comeau
Dept of Chemistry
Ohio State University
BITNET:  TS3655@OHSTMVSA

john@bc-cis.UUCP (John L. Wynstra) (02/09/88)

In article <386@osupyr.UUCP> ddc@osupyr.UUCP (Don Comeau) writes:
|
|Since everyone else is suggesting their addition to C, here is one I
|think would be useful.  Why are ++ and -- still limited to lvalues?  I
|think ++expresion should be an expression which has the value
|expression+1.
|
|Are there any good reason why this hasn't been done?
|
	Yes, can you say redundant?  You said it yourself, the thing is
`(expression)+1', why have another name for the same thing?  And as to
the traditional use, why would ++ or -- ever apply to anything but
lvalues (remembering that *(pointer-expression) is one)?

	You guys on the ANSI committee, leave my C alone!  (I like it K&&R
thank'ee, black, no sugar, please.)

-- 
	John L. Wynstra
	US mail:	Apt. 9G, 43-10 Kissena Blvd., Flushing, N.Y., 11355
	UUCP:		john@bc-cis.UUCP { eg, rutgers!cmcl2!phri!bc-cis!john }

carroll@snail.CS.UIUC.EDU (02/11/88)

	And if you really want to see the operator before the expression
(ala ++expression), then just  use 1+(expression). No  problem.

blm@cxsea.UUCP (Brian Matthews) (02/12/88)

Don Comeau (ddc@osupyr.UUCP) writes:
|Since everyone else is suggesting their addtion to C, here is one I
|think would be useful.  Why are ++ and -- still limited to lvalues?  I
|think ++expresion should be an expression which has the value
|expression+1.
|Are there any good reason why this hasn't been done?

Yes.  ++ and -- have the side effect of incrementing or decrementing the
lvalue they're applied to, so they have to be applied to lvalues.  How
does one increment x + y (as in ++(x+y)) or m + 4 (as in ++(m+4))?  If
you want the value of one more than an expression and don't want the
increment side effect, that's easy to do in C also:  expression + 1

-- 
Brian L. Matthews                               "A power tool is not a toy.
...{mnetor,uw-beaver!ssc-vax}!cxsea!blm          Unix is a power tool."
+1 206 251 6811
Computer X Inc. - a division of Motorola New Enterprises

al@gtx.com (0732) (02/12/88)

In article <386@osupyr.UUCP> ddc@osupyr.UUCP (Don Comeau) writes:
>
>Since everyone else is suggesting their addtion to C, here is one I
>think would be useful.  Why are ++ and -- still limited to lvalues?  I
>think ++expresion should be an expression which has the value
>expression+1.
>
>Are there any good reason why this hasn't been done?
>

A better question is "Is there any good reason why this should be done?".
In what situation would ++(a+b) provide any advantage over a+b+1 ?

Generalization may be good if it provides some simplification, but in
this case, neither the compiler writer nor the programmer benefit.

I can't think of any other case in which the semantics of an expression
depend on whether or not the arguments are lvalues.

>
>Flames welcome!  Maybe I'd learn something.
>

Sorry if I wasn't abusive enough.

    ----------------------------------------------------------------------
   | Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA |
   | {ihnp4,cbosgd,decvax,hplabs,amdahl}!sun!sunburn!gtx!al (602)870-1696 |
    ----------------------------------------------------------------------

paul@devon.UUCP (Paul Sutcliffe Jr.) (02/14/88)

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:
> > Since everyone else is suggesting their addition to C, here is one I
> > think would be useful.  Why are ++ and -- still limited to lvalues?  I
> > think ++expresion should be an expression which has the value
> > expression+1.
> > 
> > Are there any good reason why this hasn't been done?

> 	Yes, can you say redundant?  You said it yourself, the thing is
> `(expression)+1', why have another name for the same thing?  And as to
> the traditional use, why would ++ or -- ever apply to anything but
> lvalues (remembering that *(pointer-expression) is one)?
> 	You guys on the ANSI committee, leave my C alone!  (I like it K&&R
> thank'ee, black, no sugar, please.)

John, your coffee cup (as well as your statement) are full of holes.
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

Of course, for lvaluse, ++ and -- are K&R 'C', so you must have them,
yet you say Don's suggestion is bad.  Think about it.

- paul

-- 
Paul Sutcliffe, Jr.				       +----------------------+
						       |  THINK ...           |
UUCP (smart):  paul@devon.UUCP			       |            or THWIM  |
UUCP (dumb):   ...rutgers!bpa!vu-vlsi!devon!paul       +----------------------+

ok@quintus.UUCP (Richard A. O'Keefe) (02/14/88)

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.

aeusesef@csuna.UUCP (sean fagan) (02/15/88)

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:
>> > Since everyone else is suggesting their addition to C, here is one I
>> > think would be useful.  Why are ++ and -- still limited to lvalues?  I
>> > think ++expresion should be an expression which has the value
>> > expression+1.
They are limited to lvalues because ++ and -- are, respectively,
incrementors and decrementors.  It makes no sense to increment an expression
(you can increment the value of it, but not the expression itself), whereas
incrementing an lvalue makes perfect sense.
[++lvalue is redundant]
>	lvalue = lvalue + 1
>	lvalue += 1
yeah, but then you have something like
    val = .... lvalue++ .... lvalue++ .... lvalue++;
(they are, hopefully, different lvalues, but not necessarily)
Your way, you have to do
    val = .... (lvalue += 1) .... (lvalue += 1) .... (lvalue += 1);
Hmm.. I think I'd take the ++ operators.  Now, if we use ++(expr), we get
    val = .... ++(a+b+c) ... ++(a+b+c) ... ++(a+b+c);
or
    val = .... (a+b+c+1) ... (a+b+c+1) ... (a+b+c+1);
Same amount of typing (but less shifting on my keyboard).  The only reason I
could see having the '++(expr)' is so that the '1' added would be multiplied
by the size of the expression.  However, I've never had a need to do that,
and overloading this operator in such a foolish fashion is, well, foolish.

>Paul Sutcliffe, Jr.
>UUCP (smart):  paul@devon.UUCP

 -----

 Sean Eric Fagan          Office of Computing/Communications Resources
 (213) 852 5742           Suite 2600
 1GTLSEF@CALSTATE.BITNET  5670 Wilshire Boulevard
                          Los Angeles, CA 90036
{litvax, rdlvax, psivax, hplabs, ihnp4}!csun!csuna!aeusesef

nevin1@ihlpf.ATT.COM (00704a-Liber) (02/16/88)

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:
.> > Since everyone else is suggesting their addition to C, here is one I
.> > think would be useful.  Why are ++ and -- still limited to lvalues?  I
.> > think ++expresion should be an expression which has the value
.> > expression+1.
.
.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
.

Not quite.  lvalue++ is a little bit tougher to come up with an equivalent
expression.  The following should be equivalent to lvalue++:

lvalue += 1 , lvalue - 1

which is something I DON'T want lying around.  Also, you would have to
parenthesize like crazy.

.Of course, for lvaluse, ++ and -- are K&R 'C', so you must have them,
.yet you say Don's suggestion is bad.  Think about it.

I thought about it and I still don't like it (sorry, Don).  For consistency's
sake, I would rather ++ and -- ALWAYS have a side effect; otherwise, code would
be much harder to maintain and little bugs would creep in because many
expressions result in lvalues and their values would mysteriously (except to
lint :-)) be incremented or decremented.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

jimp@cognos.uucp (Jim Patterson) (02/17/88)

In article <386@osupyr.UUCP> ddc@osupyr.UUCP (Don Comeau) writes:
>
>Since everyone else is suggesting their addtion to C, 
Actually, the ANSI committee isn't much interested anymore (since they're
trying to get what they already have in a form everyone is happy with), but...

> Why are ++ and -- still limited to lvalues?  I
>think ++expresion should be an expression which has the value
>expression+1. 
There's a very simple reason. ++x isn't an operator to just return x+1.
It's purpose is to increment x by 1 and then return the new value of
x. If x is an expression, you can't increment it because it would then
be a different expression.

I've seen a lot of confusion over the ++ and -- operators, typically
by novice users who think that ++ is synonymous with "+1". It isn't.
Making it synonymous in the case of expressions but not in the case of
actual lvalues (if that's what you propose) would be very confusing.
It's not always clear even whether an expression is an lvalue or not.
-- 
Jim Patterson                              Cognos Incorporated
UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707    
PHONE:(613)738-1440                        3755 Riverside Drive
                                           Ottawa, Ont  K1G 3Z4

bts@sas.UUCP (Brian T. Schellenberger) (02/21/88)

In article <2354@cxsea.UUCP> blm@cxsea.UUCP (Brian Matthews) writes:
|How does one increment x + y (as in ++(x+y)) or m + 4 (as in ++(m+4))? 

Clearly, in the case ++(m+4), one increments `m' (the only lvalue); in
the case of ++(x+y), one increments either x or y, randomly chosen (if
they are integers); if they are floating-point numbers, one increments 
each by 1/2.  :-)
-- 
                                                         --Brian.
(Brian T. Schellenberger)				 ...!mcnc!rti!sas!bts

DISCLAIMER:  Whereas Brian Schellenberger (hereinafter "the party of the first