I have used the comma operator a number of times with these new "modern" system calls (MACH) that don't return the value you really want but instead an error indicator (why not have "legal" and "illegal" values like Unix always did?) This is really ugly but puts the call into if statements and assignments so I am not confused as to whether the result is used anywhere else:
Mark>I was wondering why it seems that the comma operator is so rarely used. Mark>The only time I ever see it is in 'for' loops. Is it really considered Mark>*that* bad by the programming public at large? Any comments?
I've used it to make large macros act like functions which return a value like this:
#define stuff(x,y) exp1, exp2, exp3
where exp{1,2,3} are expressions.
The key point is that the value of stuff(x,y) is the value of exp3. It's analogous to a function doing
return exp3;
It may be smart to parenthesize the right hand side of the macro.
-- | UUCP-stuff: rutgers!devon!sojurn!mike | "It muddles me rather" | | Slow-stuff: 2129 Old Phila. Pike | Winnie the Pooh | | Lancaster, Pa. 17602 | with apologies to | | Fast-stuff: (717) 396-9897 | A. A. Milne |
> >>Calls both foo() and bar(), but the "return code" of mymac is the value > >>returned by bar().
> I've always believed that it should be CARVED IN STONE that one should > always, always, always, without exception, code macros so that arguments > are evaluated EXACTLY ONCE and ONLY ONCE. Not less than once and not > more than once.
Well, if you do, at least give the reader of your code a fair warning by using all UPPER CASE for the macro.
#define MYMAC(a) (foo(a), bar(a))
The upper case letters are a clear warning: "This is a macro. The argument may be evaluated zero, once or many times."
printf("MYMAC(a++) returned %d\n", MYMAC(a++)); printf("a ended up as %d in main\n", a); printf("This should not be too surprising.\n"); printf("You have been warned!\n");
-- --------------------------------------------------------------------------- -- | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden | | Email: j...@lulea.telesoft.se; Voice: (+46) 92075471; Fax: (+46) 92075490 | --------------------------------------------------------------------------- --
One of the places that commas (and ?:, which I actually use fairly frequently) is in the writing of preprocessor macros which act non-astonishingly inside 'if' statements. As a trivial example:
#define DEBUG_MSG !debug ? 0 : printf
Twisted, but it works...
Amanda Walker ama...@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "On the whole human beings want to be good, but not too good and not quite all the time." --George Orwell.
In article <1991Sep25.014018.23...@MDI.COM> mitch...@MDI.COM (Bill Mitchell) writes:
I've always believed that it should be CARVED IN STONE that one should always, always, always, without exception, code macros so that arguments are evaluated EXACTLY ONCE and ONLY ONCE. Not less than once and not more than once.
The assert macro violates this condition. It would be kinda pointless if it didn't. I've even been hosed by trying to do work inside an assert macro argument. How embarassing.
i...@prg.ox.ac.uk (Ian Collier) writes: >I use it all the time (especially in IOCCC entries :-) ), either as in the >above (except without the spaces :-)), or in a more complex thing, like > while(i++<j) > x=some_action(i), > y=other_result(i); > do_something(x,y), > etc, etc; > the_next_bit(); >It somehow looks better without braces. The way it is written clearly >indicates the structure, and IMHO it doesn't matter whether the punctuation >marks are commas or semicolons, or whether or not there are braces. It does
Well unfortunately for you it _does_ matter to the C compiler! What you are saying is that the next maintainer of your programs has to _read_ _carefully_and_understand_ every single line you write in order to perform any reliable work on your program. Now consider:
The ground rules: NEVER NEVER NEVER NEVER omit the B____Y braces!!!!!! ALWAYS put an open brace after the while (if etc.) closing parenthesis, ALWAYS indent, ALWAYS return to the preceding indentation level with a '}', and ALWAYS indent by exactly the same amount.
NOW, the meaning of the code can be reliably inferred by studying it A LINE AT A TIME! HAve I forgotten a brace? No, because directly under the while I see one. Even if there are ten pages between the while and the }, who cares? I am returning to a previous indentation level, so a brace MUST be placed. And so on.
BTW, did you notice I put one ';' in your code? No? I rest my case.
-- Regards,
Ron House. (s64...@zeus.usq.edu.au) (By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)
In article <1991Sep25.010136.23...@MDI.COM> mitch...@MDI.COM (Bill Mitchell) writes: < In article <5...@ksr.com> j...@ksr.com (John F. Woods) writes: << Always code as if the guy who ends up maintaining your code will be a << violent psychopath who knows where you live. Code for readability. < < Damn right!
Yup.
Or as someone's .sig says: "Professional programming is paranoid programming." The rest of the system IS out to get both you AND your code!
-- John Baldwin jo...@searchtech.com search technology, inc. uupsi!srchtec!johnb 4725 peachtree corners cir., ste 200 jo...@srchtec.uucp norcross, georgia 30092
In <FOX.91Sep26131...@abaco.nyu.edu> f...@cs.nyu.edu (David Fox) writes:
>In article <1991Sep25.014018.23...@MDI.COM> mitch...@MDI.COM (Bill Mitchell) writes: > I've always believed that it should be CARVED IN STONE that one should > always, always, always, without exception, code macros so that arguments > are evaluated EXACTLY ONCE and ONLY ONCE. Not less than once and not > more than once. >The assert macro violates this condition. It would be kinda >pointless if it didn't. I've even been hosed by trying to >do work inside an assert macro argument. How embarassing.
It may be true that assert() on many current systems does not obey this rule, however it's worth pointing out that both the ANSI 'C' standard and POSIX.1 require that assert() evaluates its argument exactly once.
The only exemptions these standards make is that getc() and putc() are allowed to evaluate their stream arguments more than once. There is no exemption for assert(). -- Geoff Clare <g...@root.co.uk> (USA UUCP-only mailers: ...!uunet!root.co.uk!gwc) UniSoft Limited, London, England. Tel: +44 71 729 3773 Fax: +44 71 729 3273
In article <3...@root44.co.uk> g...@root.co.uk (Geoff Clare) writes:
It may be true that assert() on many current systems does not obey this rule, however it's worth pointing out that both the ANSI 'C' standard and POSIX.1 require that assert() evaluates its argument exactly once.
That happens not to be the case. From the ANSI C standard:
4.2 Diagnostics <assert.h>
If NDEBUG is defined as a macro name at the point in the source file where <assert.h> is included, the assert macro is defined simply as
#define assert(ignore) ((void) 0)
The assert macro shall be implemented as a macro, not as an actual function. If the macro definition is suppressed in order to access an actual function, the bahavior is undefined.
-- "The best way to protect your liberty is to protect the liberty of others. Liberty is not a pie; it's an insurance program." -- Carl Kadie Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA Internet: mcdan...@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel
