alen@cogen.UUCP (Alen Shapiro) (11/20/87)
Firstly, thanks to ALL who replied by mail and net. It seems that there is no "knock-em-dead" reason for the statement #define XXX (-1) to have ()s round the "-1". i.e. On an ANSI standard C compiler (when one is finally decided on :-)) there are NO situations where LEGAL use of XXX results in a LEGAL program that differs in function with or without ()s surrounding the "-1". Certainly antequated C compilers will probably screw-up and make statements like a = XXX into a =- 1 (which (strictly speaking) is no longer legal C). There IS a reason for fully bracketing expressions within #define since #define XXX a+b followed by y * XXX is probably not what is meant There is also a reason for fully bracketing ALL pseudo variables within preprocessor functions like #define XXX(a,b) ((a)+(b)) in case 'a' or 'b' are expressions themselves when used in the code. The closest to a REAL reason for not using #define XXX -1 came from Steve Schlaifer who suggested that x= -XXX becomes x= --1 which unfortunately is not legal C or it would have been a superb counter. There IS the case where #define XXX -i (note the "i" not "1" here) which results in legal C but does not answer the original question exactly. In this case there is also an issue of good coding (what was the person doing with a global variable manipulated from a #define - can you say "side-effect"). The answer I will use in this case will be one of style. It is good practise to ALWAYS bracket expressions in case they come back to bite you or you happen to port through an old compiler. Always bracketing expressions (it should become a habit) will save debugging time and the programmer should not be concerned with special cases that are immune to the specific effect (in case, being human, (s)he misses an important counter). So, thanks again, I don't feel quite as much of an idiot now (all I have to work on is being an a** hole :-)) --alen the Lisa slayer (it's a long story)
jc@minya.UUCP (11/26/87)
> The answer I will use in this case will be one of style. It is good practise > to ALWAYS bracket expressions in case they come back to bite you or you > happen to port through an old compiler. Always bracketing expressions > (it should become a habit) will save debugging time and the programmer > should not be concerned with special cases that are immune to the > specific effect (in case, being human, (s)he misses an important counter). When I was a novice C programmer, I frequently made the mistake of trying to use the precedence rules to save a few keystrokes of typing; after several long hours spent tracking down bugs that were corrected by a pair of parens, I learned my lesson. Since then, I've noticed that many experience C hackers routinely over-parenthesize their code. It's easier than debugging. One of the minor problems with C is that there are just too many operators for the memory of most mere humans. Also, some of the precedence rules are, while not exactly counter-intuitive, at least somewhat non-intuitive. I've tried to teach this lesson to quite a few up-and-coming C programmers since then. They never listen, of course. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)