One more point regarding = and == (more flamage)

[David A Keldsen]

>In article <13603 at helios.TAMU.EDU> byron at archone.tamu.edu (Byron Rakitzis) writes:
>>a)	while (*foo++ = *bar++)
>>b)	while ((*foo++ = *bar++) != 0)
>>
>>All I can say is, if you code in style (a) rather than style (b), don't
>>expect anyone reading your code to enjoy the experience.
>>
>>Henry, are you behind me on this one? ...

henry at zoo.toronto.edu (Henry Spencer) writes:

>Yes.  Deliberately using a construct that looks like a well-known and subtle
>programming error is a mistake.  Your successor, reading your code, should
>*never* have to ask himself "is this really right?"; if there is reason for
>doubt, either comment the code or change it.

I agree with the principle, but I disagree that it applies here.  The 
programmer must balance clarity-by-standard-idiom and clarity-by-explicitness.

>From K&R1 (p. 101):
        ...
        while (*s++ = *t++)
        ...

"Although this may seem cryptic at first sight, the notational convenience
is considerable, and the idiom should be mastered, if for no other reason
than that you will see it frequently in C programs."

I find the idiomatic usage to be clearer, because it is easier to recognize.

Dak
-- 
David A. 'Dak' Keldsen of SoftQuad, Inc. email: dak at sq.com  phone: 416-963-8337
"Perhaps the most universally recognized tool for improving a professional 
programmer's productivity is C.  Not the C language...but the C additive, 
Caffeine." -- "COMPUTER LANGUAGE" April 1989 Product Wrap-Up Column by Ted Bahr