Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!oakhill!stevenw
From: stevenw@oakhill.UUCP (Steven Weintraub)
Newsgroups: comp.lang.c
Subject: Re: comma operator
Summary: Or the standard
Message-ID: <2271@sunset.oakhill.UUCP>
Date: 4 Aug 89 13:52:44 GMT
References: <3287@ohstpy.mps.ohio-state.edu> <10453@claris.com>
Organization: Motorola Inc. Austin, Tx
Lines: 63

In article <10453@claris.com>, kevin@claris.com (Kevin Watts) writes:
> From article <3287@ohstpy.mps.ohio-state.edu>, by SMITHJ@ohstpy.mps.ohio-state.edu:
> > In article <1351@cbnewsl.ATT.COM>, mpl@cbnewsl.ATT.COM (michael.p.lindner) writes:
> >> ***FLAME ON!***
> >> Sigh.  RTFM!  The comma operator guarantees left to right evaluation,
> >> and fprintf(...) and exit(...) ARE valid expressions in C.
> >> sputter sputter - flame off.
> > 
> > Maybe I'm mistaken, but I'm sure that all the documentation I've read warns
> > that the *comma* operator ----does not----- guarantee evaluation in any order.
> > Specifically, the Microsoft 5.0 manual mentions this.
> > 
> Hmm, I'll have to check my copy when I get home.  If you're right, it's broken.
> 
> I quote from "Standard C", p.88, by P.J. Plauger & Jim Brodie (the secretary
> and chairman of X3J11):
> 	You write X,Y to first evaluate X as a side-effects context
> 	expression and then to evaluate Y.  There is a sequence point
> 	between the evaluation of the two operands.
> 
> I hope that settles the matter for everyone.  The order IS guaranteed!

In fact the standard is even more direct and simpler, to quote (from my
    outdated version - capital THEN mine):

3.3.17 Comma operator

syntax :     expression : assignment-expression
			  expression , assignment-expression

semantics : The left operand of the operator is evaluated as a void expression;
	    there is a sequence point after its evaluation.  THEN the right
	    operand is evaluated;  the result has its type and value.


And now since I have your attention I'll add my two cents on where I place
a comma.  There are two places.  One is the 'for' statement as has been
countlessly mentioned here.  The other is in macro calls, where there is
a posibility a parameter will change in the call.  For example:

#define square(x)   (temp = x,(temp * temp))

(No flames about the example, it is chosen for simplicity).  Now how does
the arguement change.  Try calling it with:

x = 4;
a = square(x++);

With the temp, a = 16 and x = 5: without it a = 20 and x = 5.

Of course you have the overhead of defining the temporary variable in the
program that uses the call.

                   enough from this mooncalf - Steven
----------------------------------------------------------------------------
These opinions aren't necessarily Motorola's or Remora's - but I'd like to
think we share some common views.
----------------------------------------------------------------------------
Steven R Weintraub                             | O Lord,
...!cs.utexas.edu!oakhill!stevenw              |   let me talk gently,
Motorola Inc.  Austin, Texas                   | for I might have to eat my
(512) 891-3023 (office) (512) 453-6953 (home)  |   words tomorrow.
----------------------------------------------------------------------------