Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!bloom-beacon!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.lang.c
Subject: Re: comma operator
Message-ID: <2427@bloom-beacon.MIT.EDU>
Date: 21 Jan 88 11:39:30 GMT
References: <3819@sigi.Colorado.EDU> <8599@ism780c.UUCP> <1866@bsu-cs.UUCP> <4006@june.cs.washington.edu> <3586@sdcc6.ucsd.EDU> <4018@june.cs.washington.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jfc@athena.mit.edu (John F Carr)
Organization: Massachusetts Institute of Technology
Lines: 30

In article <4018@june.cs.washington.edu> pardo@uw-june.UUCP (David Keppel) writes:
>[ how could the comma operator cause slower code? ]

      Because the comma operator guarantees an order of evaluation on two
      statements that the compiler might otherwise rearrange to produce more
      efficient code.

      	    ++x, ++y;
      	    if (x % n) { ... }

      If the comma was replaced by a semicolon, the compiler could rewrite it as

      	    ++y;
      	    if (++x % n) { ... }

      Which would be faster on many machines.


I thought that "," and ";" both guaranteed order of evaluation.
I have not heard anything to the contrary.  The difference, as I 
see it, is that "," orders statements within a statement (I don't
remember which are called statements and which expressions).  I 
have always assumed that ;'s determined the order of evaluation
but that an optimizing compiler could reorder any statements as long
as the results are identical with the results of the written order.

Is there any reason that ";" seperated statements can be reordered 
but "," seperated statements can't be?

  --John Carr   (jfc@ATHENA.MIT.EDU)