When do you use "if ( a = b )"? (was Re: Funny mistake)

Jody Hagins hagins at gamecock.rtp.dg.com
Sat Mar 23 02:21:17 AEST 1991


In article <11309 at dog.ee.lbl.gov>, torek at elf.ee.lbl.gov (Chris Torek) writes:
|> [I wrote: `if your compiler generates different code for embedded
|> assignments than for separate assignments, that compiler is not worth
|> what you paid for it.']
|> 
|> In article <dxj+VD at ppcger.ppc.sub.org> Sepp at ppcger.ppc.sub.org (Josef Wolf)
|> writes:
|> >You might be right in this point of view, but...
|> [and goes on to argue that embedded assignment tends to be clearer.]
|> 
|> I happen to agree---most often, a loop like:
|> 
|> 	while ((c = getchar()) != EOF) {
|> 		do some work;
|> 	}
|> 
|> is MUCH better, stylistically, than
|> 
|> 	c = getchar();
|> 	while (c != EOF) {
|> 		do some work;
|> 		c = getchar();
|> 	}
|> 
|> (Never mind translating into `for' loop syntax :-) )
|> 
|> >Well, the above is _my_ opinion. You have to find _your_ way to get
|> >around this problem.
|> 
|> Do not make the mistake of thinking that every argument I make is a
|> direct clue to my own opinions.  I could, for instance, show how VMS
|> is better than <pick some version here> Unix at some particular task.
|> (Such tasks do exist, especially with older Unixes.)  Nonetheless, I
|> have managed to avoid VMS systems for many years now, and plan to
|> continue avoiding them.
|> 
|> In this particular case, I would be quite happy with a compiler that
|> warns about
|> 
|> 	if (a = expr) ...
|> 
|> but not about
|> 
|> 	if ((a = expr) != 0) ...



That's exactly what Borland's C compilers do.


|> 
|> and I tend to write the latter when I mean `assign, then test the result'.
|> -- 
|> In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
|> Berkeley, CA		Domain:	torek at ee.lbl.gov
|> 

-- 

Jody Hagins             
hagins at gamecock.rtp.dg.com    
Data General Corp.      
62 Alexander Dr.        
RTP, N.C.  27709        
(919) 248-6035          

Nothing I ever say reflects the opinions of DGC.



More information about the Comp.lang.c mailing list