Usage of comma operator

9595 views
Skip to first unread message

Mark M Lacey

unread,
Sep 18, 1991, 10:21:47 PM9/18/91
to
I was wondering why it seems that the comma operator is so rarely used.
The only time I ever see it is in 'for' loops. Is it really considered
*that* bad by the programming public at large? Any comments?
--
Mark M. Lacey [la...@cps.msu.edu]
All reasonable and thoughtful responses are welcome.
[reasonable (adj.) - using or showing reason, or sound judgement; sensible]
[thoughtful (adj.) - full of thought; medatative; thinking]

Steve Coltrin

unread,
Sep 19, 1991, 1:39:10 AM9/19/91
to
la...@lobster.cps.msu.edu (Mark M Lacey) writes:

>I was wondering why it seems that the comma operator is so rarely used.
>The only time I ever see it is in 'for' loops. Is it really considered
>*that* bad by the programming public at large? Any comments?

I don't think it's _bad_; it's just not very useful except in for
loops. At least, I can't think of why I'd use it elsewhere.

--
spco...@uokmax.ecn.uoknor.edu
Support your local medical examiner - die strangely

Dennis Boone

unread,
Sep 19, 1991, 7:11:13 PM9/19/91
to
In article <1991Sep19.0...@msuinfo.cl.msu.edu> la...@lobster.cps.msu.edu (Mark M Lacey) writes:
>I was wondering why it seems that the comma operator is so rarely used.
>The only time I ever see it is in 'for' loops. Is it really considered
>*that* bad by the programming public at large? Any comments?

It is kind of hard to see commas in the morass of other punctuation that
C always involves. I occasionally use it if I'm incrementing two pointers
at the same time, and there's nothing else in the loop body, rather than
tying up all sorts of extra space with brackets. (I'm NOT a K&R style lover)

Like everything else, I suppose, it's good if used right and bad if used
wrong.

De
--
== morons have no questions. ==

Mark M Lacey

unread,
Sep 19, 1991, 5:25:32 PM9/19/91
to
Mark = Mark M. Lacey [la...@cps.msu.edu]
Steve = Steve Coltrin [spco...@uokmax.ecn.uoknor.edu]
Rob = Rob Tulloh [ro...@itx.isc.com]

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?

Steve: I don't think it's _bad_; it's just not very useful except in for
Steve: loops. At least, I can't think of why I'd use it elsewhere.

Rob: Well, I hadn't seen it used much either outside of the for loop, but
Rob: in Plaugher's latest book I discovered quite a few of the following
Rob: constructs:

Rob: if (condition)
Rob: var = value, anothervar = anothervalue;

Rob: This does away with the need for braces. I am tempted to use this myself
Rob: unless someone has a good point agains using this style. Opinions anyone?

That is the type of thing I was thinking of, along with:

for (expr1; expr2; expr3)expr4, expr5;

It shouldn't make any difference to a compiler whether you use braces or
just seperate them with a comma, so I was wondering why I never seem to
see code that has something like this. Obviously, this could be abused
and you could have an entire program full of:

for (expr1, expr2, expr3; expr4, expr5, expr6; expr7, expr8,
expr9) expr10, expr11, expr12, expr13, etc.

But for simple things that involve 2 or even 3 expressions, it seems
like it isn't that bad to do something like this. I mean, I have seen:

if (a<b)
{ temp = a; a = b; b = temp; }

why not:

if (a<b) temp = a, a = b, b = temp;

Some people seem to like braces ALWAYS on if/for/while's, even if there
is only one expression. I guess it is just a matter of personal
preference, but I think the second example directly above reads
well, and the intentions are clear. Like everything, of course, there
is room for abuse.

Graham Kean;;g_kean

unread,
Sep 19, 1991, 6:24:51 PM9/19/91
to
>>la...@lobster.cps.msu.edu (Mark M Lacey) writes:
>>>I was wondering why it seems that the comma operator is so rarely used.
>>>The only time I ever see it is in 'for' loops. Is it really considered
>>>*that* bad by the programming public at large? Any comments?

>> I don't think it's _bad_; it's just not very useful except in for
>>loops. At least, I can't think of why I'd use it elsewhere.

I find it useful in while loops, as in:

unsigned i;
FILE *f;
....
while (i = getw(f), !feof(f))
{
....

-------------------------------------------------------------------------
Graham Kean gk...@ccu1.aukuni.ac.nz
University of Auckland
-------------------------------------------------------------------------

Barry Margolin

unread,
Sep 19, 1991, 7:17:23 PM9/19/91
to
In article <1991Sep19.2...@msuinfo.cl.msu.edu> la...@starfish.cps.msu.edu (Mark M Lacey) writes:
>Rob: if (condition)
>Rob: var = value, anothervar = anothervalue;
>
>Rob: This does away with the need for braces. I am tempted to use this myself
>Rob: unless someone has a good point agains using this style. Opinions anyone?
>
>That is the type of thing I was thinking of, along with:
>
> for (expr1; expr2; expr3)expr4, expr5;
...

>Some people seem to like braces ALWAYS on if/for/while's, even if there
>is only one expression. I guess it is just a matter of personal
>preference, but I think the second example directly above reads
>well, and the intentions are clear. Like everything, of course, there
>is room for abuse.

I think it's mostly a matter of style. Many people learn their style from
the books or other programmers they learned from, so there tends to be some
amount of consistency across the industry. I've never seen commas used
extensively in the above ways in text books or code I've seen, so it tends
not to perpetuate.

As for why the style setters don't use that style, I can think of several
possible reasons.

First, many C programmers were formerly programmers in other languages, and
most other languages don't have anything like the comma operator. They
learned to use it in those special cases where it really solves a problem,
such as the for-statement, but in other cases they stick to their old
statement-oriented habits.

Second, there's a level of consistency and simplicity maintained when you
use statement sequencing rather than expression sequencing. It's easier to
use the same style for all compound statement bodies. If you sometimes use
comma, then you have to remember to switch to semicolon when the body
includes non-expression statements. However, semicolon works all the time.

A similar argument applies to why some people put braces around the body
even when there's only one statement. It allows you to code a bit more by
reflex, rather than having to think about minute details. Also, it allows
you to add more statements to the body with the minimal amount of editing;
it's already set up for a sequence of statements, so you can just add and
delete statements as needed, without having to add extraneous syntax.

--
Barry Margolin, Thinking Machines Corp.

bar...@think.com
{uunet,harvard}!think!barmar

John Nash

unread,
Sep 19, 1991, 9:17:09 PM9/19/91
to
In article <robtu.685300138@mexia>, ro...@itx.isc.com (Rob Tulloh) writes:

>spco...@uokmax.ecn.uoknor.edu (Steve Coltrin) writes:
>
>>la...@lobster.cps.msu.edu (Mark M Lacey) writes:
>
>>>I was wondering why it seems that the comma operator is so rarely used.
>>>The only time I ever see it is in 'for' loops. Is it really considered
>>>*that* bad by the programming public at large? Any comments?
>
>> I don't think it's _bad_; it's just not very useful except in for
>>loops. At least, I can't think of why I'd use it elsewhere.
>
>Well, I hadn't seen it used much either outside of the for loop, but
>in Plaugher's latest book I discovered quite a few of the following
>constructs:
>
> if (condition)

> var = value, anothervar = anothervalue;
>
>This does away with the need for braces. I am tempted to use this myself
>unless someone has a good point agains using this style. Opinions anyone?
>
>Rob Tulloh


Yeah... I have found it useful in the following context:

(video_mode() == 7) ? (background = BLACK, foregound = WHITE) :
(background = CYAN, foreground = MAGENTA);

when accounting for colour vs mono cards under MS-DOS. (I don't really
use magenta on cyan <g>). Just think of the number of lines that
I've saved compared to if I'd used if..else and braces (and I don't
think it's hard to read).

Just my $0.02...

cheers,
John Nash | Internet: Na...@biologysx.lan.nrc.ca
Institute for Biological Sciences | or: num2...@mbds.nrc.ca
National Research Council of Canada| Ottawa, Canada K1A 0R6.
==> Disclaimer: All opinions are mine, not NRC's! <==

Rob Tulloh

unread,
Sep 19, 1991, 1:08:58 PM9/19/91
to
spco...@uokmax.ecn.uoknor.edu (Steve Coltrin) writes:

>la...@lobster.cps.msu.edu (Mark M Lacey) writes:

>>I was wondering why it seems that the comma operator is so rarely used.
>>The only time I ever see it is in 'for' loops. Is it really considered
>>*that* bad by the programming public at large? Any comments?

> I don't think it's _bad_; it's just not very useful except in for
>loops. At least, I can't think of why I'd use it elsewhere.

Well, I hadn't seen it used much either outside of the for loop, but


in Plaugher's latest book I discovered quite a few of the following
constructs:

if (condition)
var = value, anothervar = anothervalue;

This does away with the need for braces. I am tempted to use this myself
unless someone has a good point agains using this style. Opinions anyone?

Rob Tulloh
--
INTERACTIVE Systems Corp. Tel: (512) 343 0376 Ext. 116
9442 Capital of Texas Hwy. North Fax: (512) 343 0376 Ext. 161 (not a typo!)
Arboretum Plaza One, Suite 700 Net: rob...@isc.com (polled daily)
Austin, Texas 78759 GEnie: R.TULLOH (polled monthly)

Dik T. Winter

unread,
Sep 20, 1991, 6:06:11 AM9/20/91
to
> Obviously, this could be abused
> and you could have an entire program full of:
>
> for (expr1, expr2, expr3; expr4, expr5, expr6; expr7, expr8,
> expr9) expr10, expr11, expr12, expr13, etc.
>
Yup. From my .plan:
int a=10000,b,c=2800,d,e,f[2801],g;main(){for(;b-c;)f[b++]=a/5;for(;d=0,g=c*2;c
-=14,printf("%.4d",e+d/a),e=d%a)for(b=c;d+=f[b]*a,f[b]=d%--g,d/=g--,--b;d*=b);}
--
dik t. winter, cwi, amsterdam, nederland
d...@cwi.nl

Dwayne Bailey

unread,
Sep 20, 1991, 5:21:48 AM9/20/91
to
In article <1991Sep19....@uokmax.ecn.uoknor.edu> spco...@uokmax.ecn.uoknor.edu (Steve Coltrin) writes:
>la...@lobster.cps.msu.edu (Mark M Lacey) writes:
>
>>I was wondering why it seems that the comma operator is so rarely used.
>>The only time I ever see it is in 'for' loops. Is it really considered
>>*that* bad by the programming public at large? Any comments?
>
> I don't think it's _bad_; it's just not very useful except in for
>loops. At least, I can't think of why I'd use it elsewhere.
>

Actually, I sometimes find it useful in macros. If I need to perform
multiple statements, yet still have my macro "return" a value, the comma
operator is useful.

#define mymac(a) (foo(a), bar(a))

Calls both foo() and bar(), but the "return code" of mymac is the value
returned by bar().

--
------------------------------------------------------------------
stratsft!dwayne + Strategic Software IS me, so my
Dwayne Bailey + opintions ARE those of my
Strategic Software + company

Kevin D. Quitt

unread,
Sep 20, 1991, 2:15:41 PM9/20/91
to
In article <1991Sep19....@Think.COM> bar...@think.com writes:
>A similar argument applies to why some people put braces around the body
>even when there's only one statement. It allows you to code a bit more by
>reflex, rather than having to think about minute details. Also, it allows
>you to add more statements to the body with the minimal amount of editing;
>it's already set up for a sequence of statements, so you can just add and
>delete statements as needed, without having to add extraneous syntax.

Besides which, in any reasonable editor (with macro support), generating
the braces and placing them correctly is a single key-stroke.

--
_
Kevin D. Quitt srhqla!venus!kdq kdq%ve...@sr.com
3D systems, inc. 26081 Avenue Hall Valencia, CA 91355
VOICE (805) 295-5600 x430 FAX (805) 257-1200

96.37% of all statistics are made up.

LEWIS WILLIAM M JR

unread,
Sep 20, 1991, 7:12:24 PM9/20/91
to
.. much deleted

>
> if (a<b) temp = a, a = b, b = temp;
>
Tom Plum recommends this usage in "Learning to Program in C" as a reminder
to the maintenance programmer that the statements must be kept together.

Todd Pfaff

unread,
Sep 20, 1991, 6:20:26 PM9/20/91
to
>But for simple things that involve 2 or even 3 expressions, it seems
>like it isn't that bad to do something like this. I mean, I have seen:
>
> if (a<b)
> { temp = a; a = b; b = temp; }
>
>why not:
>
> if (a<b) temp = a, a = b, b = temp;
>
>Some people seem to like braces ALWAYS on if/for/while's, even if there
>is only one expression. I guess it is just a matter of personal
>preference, but I think the second example directly above reads
>well, and the intentions are clear. Like everything, of course, there
>is room for abuse.
>--
>Mark M. Lacey [la...@cps.msu.edu]
>All reasonable and thoughtful responses are welcome.
>[reasonable (adj.) - using or showing reason, or sound judgement; sensible]
>[thoughtful (adj.) - full of thought; medatative; thinking]

The biggest reason I have for avoiding this type of construct is that some
source-level debuggers will single step over the entire statement in one step.
You can't step into the expression if you want to analyze it subexpression by
subexpression.

In fact, I even avoid:

> if (a<b)
> { temp = a; a = b; b = temp; }

because, similarly, the debugger may step over the entire line rather than step
statement by statement.

To see exactly what I mean, compile the following code:

main()
{
int a, b;

a=1; b=2;
a=1;
b=2;
a=1, b=2;
a=1,
b=2;
}

and try stepping through it with a debugger (I used dbxtool on a Sun/SunOS 4.1.1).

Of course, if you write bug-free code this argument doesn't apply. :-)

--
Todd Pfaff \ Internet: to...@flex.eng.mcmaster.ca
Dept. of Mechanical Engineering \ Voice: (416) 525-9140 x2902
McMaster University \ FAX: (416) 572-7944
Hamilton, Ontario, CANADA L8S 4L7 \

Yanek Martinson

unread,
Sep 22, 1991, 12:23:46 AM9/22/91
to

>loops. At least, I can't think of why I'd use it elsewhere.

The way I remember it expr,expr is allowed wherever a single expr is.
Right? Ok, let's say we have this:

int x(int,int);

....

x(1,2,3);

how would this be interpreted? x(1,(2,3)) or x((1,2),3) ???

Jim ADCOCK

unread,
Sep 23, 1991, 2:52:56 PM9/23/91
to
In article <1991Sep19.0...@msuinfo.cl.msu.edu> la...@lobster.cps.msu.edu (Mark M Lacey) writes:
>I was wondering why it seems that the comma operator is so rarely used.
>The only time I ever see it is in 'for' loops. Is it really considered
>*that* bad by the programming public at large? Any comments?

Oldtime C++ hackers tend to run away screaming whenever they see a comma.

[....after debugging thousands of lines of Cfront output, containing tens
of thousands of commas.... :-]

Amanda Walker

unread,
Sep 23, 1991, 1:33:55 PM9/23/91
to
la...@lobster.cps.msu.edu (Mark M Lacey) writes:

I was wondering why it seems that the comma operator is so rarely used.
The only time I ever see it is in 'for' loops. Is it really considered
*that* bad by the programming public at large? Any comments?

Well, two things come to mind:

a) People forget that it's an operator, or what it means.

b) Good compilers will treat ';' the same way as ',' anyway, modulo
variable references.


Amanda Walker ama...@visix.com
Visix Software Inc. ...!uunet!visix!amanda
--
"I think there's a world market for about 5 computers."
--Thomas J. Watson, Chairman of the Board, IBM (around 1948)

Rob Tulloh

unread,
Sep 24, 1991, 12:10:30 PM9/24/91
to
dwa...@stratsft.uucp (Dwayne Bailey) writes:

>In article <1991Sep19....@uokmax.ecn.uoknor.edu> spco...@uokmax.ecn.uoknor.edu (Steve Coltrin) writes:
>>la...@lobster.cps.msu.edu (Mark M Lacey) writes:
>>
>>>I was wondering why it seems that the comma operator is so rarely used.
>>>The only time I ever see it is in 'for' loops. Is it really considered
>>>*that* bad by the programming public at large? Any comments?
>>
>> I don't think it's _bad_; it's just not very useful except in for
>>loops. At least, I can't think of why I'd use it elsewhere.
>>

>Actually, I sometimes find it useful in macros. If I need to perform
>multiple statements, yet still have my macro "return" a value, the comma
>operator is useful.

>#define mymac(a) (foo(a), bar(a))

>Calls both foo() and bar(), but the "return code" of mymac is the value
>returned by bar().

Yes, I have done this quite a bit too. I think outside of for loops, this
is the most used construct involving comma. I had not seen the if,else
use until I read Plauger's book.

IMHO, one could definitely overuse comma, but in some cases I think
it makes the code more readable. How about those X11 function calls
which need to bump through an array of arguments to be passed dynamically.
I am not an X programmer, but it seems like this might be another place where
using the comma might improve readability...

XtSetArg(args[i], XtNwidth, value), i++;

I believe the examples I have seen use semicolon instead of comma. This
might be even more useful if these 2 statements needed to be lumped
under an if/else statement.

Just my $0.02 worth!

Anders Juul Munch

unread,
Sep 24, 1991, 7:24:28 AM9/24/91
to
ro...@itx.isc.com (Rob Tulloh) writes:

spco...@uokmax.ecn.uoknor.edu (Steve Coltrin) writes:

>la...@lobster.cps.msu.edu (Mark M Lacey) writes:

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?

Steve> I don't think it's _bad_; it's just not very useful except in for
Steve>loops. At least, I can't think of why I'd use it elsewhere.

Rob>Well, I hadn't seen it used much either outside of the for loop, but
Rob>in Plaugher's latest book I discovered quite a few of the following
Rob>constructs:

Rob> if (condition)
Rob> var = value, anothervar = anothervalue;

Rob>This does away with the need for braces. I am tempted to use this myself
Rob>unless someone has a good point agains using this style. Opinions anyone?

Consider this:
if (condition)
var = value; anothervar = anothervalue;

Only one little dot is changed, but the meaning is quite different. In other
words, using the comma operator like that makes it harder to read: It's
harder to get an overview of the code, because you have to be wary of that
subtle difference. And if you trust your indentation, you risk doing
something like the the famous FORTRAN error that caused a spacecraft bound
for Jupiter to fly astray (a `.' that should have been a `,').
In other places I find the comma operator extremely useful.
Primarily in macro definitions, where I want to do several things in a
single expression. And sometimes in the `init' and `next' parts of a
for(init;endcondition;next) body
loop, if the loop traverses two things simultaneously.
But I recommend against using the comma operator for the `if' or
loop body, for the above reasons.
BTW, the comma operator really is a lovely surprise for the Pascal
programmer, new to C, trying to index a twodimensional array like this:

char theArray[Range1][Range2];
...
printf("%c", theArray[index1,index2]);
...

- Anders Munch
ju...@diku.dk

Ian Collier

unread,
Sep 24, 1991, 8:22:56 AM9/24/91
to
In article <1991Sep19.2...@msuinfo.cl.msu.edu>, la...@starfish.cps.msu.edu (Mark M Lacey) wrote:
>Mark = Mark M. Lacey [la...@cps.msu.edu]
>Rob = Rob Tulloh [ro...@itx.isc.com]

>Mark: I was wondering why it seems that the comma operator is so rarely used.

>Rob: Well, I hadn't seen it used much either outside of the for loop, but


>Rob: in Plaugher's latest book I discovered quite a few of the following
>Rob: constructs:
>
>Rob: if (condition)
>Rob: var = value, anothervar = anothervalue;
>

>That is the type of thing I was thinking of, along with:
>
> for (expr1; expr2; expr3)expr4, expr5;

> if (a<b) temp = a, a = b, b = temp;

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
make it easier to make mistakes, though usually the compiler detects it. The
most common is introducing an if or for statement, which cannot be preceded
by a comma.

Doing this has one noticeable effect that hasn't yet been mentioned. I use
the Sunview version of the symbolic debuger dbx (while it isn't perfect it
often does the job), and in single step mode all the above expressions
separated by commas are executed at once. This means I can change the code
around so that the parts that work are always executed quickly, and the
parts that don't are single stepped properly.

Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk

Message has been deleted

John Kapson

unread,
Sep 24, 1991, 9:01:39 AM9/24/91
to
In article <1991Sep24.1...@odin.diku.dk> ju...@diku.dk (Anders Juul Munch) writes:
>
>Rob>Well, I hadn't seen it used much either outside of the for loop, but
>Rob>in Plaugher's latest book I discovered quite a few of the following
>Rob>constructs:
>
>Rob> if (condition)
>Rob> var = value, anothervar = anothervalue;
>
>Rob>This does away with the need for braces. I am tempted to use this myself
>Rob>unless someone has a good point agains using this style. Opinions anyone?
>
>Consider this:
> if (condition)
> var = value; anothervar = anothervalue;
>
>Only one little dot is changed, but the meaning is quite different. In other
>words, using the comma operator like that makes it harder to read: It's
>harder to get an overview of the code, because you have to be wary of that
>subtle difference. And if you trust your indentation, you risk doing
>something like the the famous FORTRAN error that caused a spacecraft bound
>for Jupiter to fly astray (a `.' that should have been a `,').

But really, who (besides a COBOL programmer) would write code with that
deliberately misleading structure?

if(condition)
conditional-statement; unconditional-statement;

I think you're taking your argument beyond the realm of reality, here.

Regards,
John Kapson

John F. Woods

unread,
Sep 24, 1991, 1:55:37 PM9/24/91
to
ju...@diku.dk (Anders Juul Munch) writes:
>ro...@itx.isc.com (Rob Tulloh) writes:
>spco...@uokmax.ecn.uoknor.edu (Steve Coltrin) writes:
>>la...@lobster.cps.msu.edu (Mark M Lacey) writes:
>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?
>Rob>Well, I hadn't seen it used much either outside of the for loop, but
>Rob>in Plaugher's latest book I discovered quite a few of the following
>Rob>constructs:
>Rob> if (condition)
>Rob> var = value, anothervar = anothervalue;
>Rob>This does away with the need for braces. I am tempted to use this myself
>Rob>unless someone has a good point agains using this style. Opinions anyone?
>Consider this:
> if (condition)
> var = value; anothervar = anothervalue;
>Only one little dot is changed, but the meaning is quite different. In other
>words, using the comma operator like that makes it harder to read:

Right.

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.

Bob Martin

unread,
Sep 24, 1991, 1:05:50 PM9/24/91
to
ro...@itx.isc.com (Rob Tulloh) writes:

>spco...@uokmax.ecn.uoknor.edu (Steve Coltrin) writes:

>>la...@lobster.cps.msu.edu (Mark M Lacey) writes:

>>>I was wondering why it seems that the comma operator is so rarely used.
>>>The only time I ever see it is in 'for' loops. Is it really considered
>>>*that* bad by the programming public at large? Any comments?

>> I don't think it's _bad_; it's just not very useful except in for
>>loops. At least, I can't think of why I'd use it elsewhere.

>Well, I hadn't seen it used much either outside of the for loop, but
>in Plaugher's latest book I discovered quite a few of the following
>constructs:

> if (condition)
> var = value, anothervar = anothervalue;

>This does away with the need for braces. I am tempted to use this myself
>unless someone has a good point agains using this style. Opinions anyone?

Before you make a decision like this, you might want to gaze at some
CFRONT output for awhile. This will almost certainly make you HATE
the comma operator.

--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting |
| rma...@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering |
| (Uncle Bob.) |-RRR--C----M--M--M-| OOA/OOD/OOP Training |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel. |

Brian Fennell

unread,
Sep 24, 1991, 1:58:20 PM9/24/91
to
In article <1991Sep23.1...@visix.com> ama...@visix.com (Amanda Walker) writes:
>la...@lobster.cps.msu.edu (Mark M Lacey) writes:
>
> I was wondering why it seems that the comma operator is so rarely used.
> The only time I ever see it is in 'for' loops. Is it really considered
> *that* bad by the programming public at large? Any comments?

The reason you see it so seldom is because it is most often used in
macros, which you aren't supposed to see.


#define poolcash(d,c) ( (d)+=(int)(c)/100 , (c)%=100 , (d)*100+(c) )

This type of macro is speedy because it skips the function overhead.
It works on registers, which a function can't do. It also returns a
value which a "do { ... } while(0)" type macro does not.

Fenn @wpi.wpi.edu

Bill Mitchell

unread,
Sep 24, 1991, 9:40:18 PM9/24/91
to
In article <robtu.685728630@mexia> ro...@itx.isc.com (Rob Tulloh) writes:
>dwa...@stratsft.uucp (Dwayne Bailey) writes:
>
>[...]

>
>>Actually, I sometimes find it useful in macros. If I need to perform
>>multiple statements, yet still have my macro "return" a value, the comma
>>operator is useful.
>
>>#define mymac(a) (foo(a), bar(a))
>
>>Calls both foo() and bar(), but the "return code" of mymac is the value
>>returned by bar().
>
>Yes, I have done this quite a bit too.

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.

#define mymac(a) (foo(a), bar(a))
main() {
int a = 1;
printf("a started out as %d in main\n", a);
printf("mymac(a++) returned %d\n", mymac(a++));
printf("a ended up as %d in main\n", a);
printf("This is easily explainable, but may be suprising.\n");
printf("Especially if the #definition of mymac(a)\n");
printf("is hidden in a header file.\n");
}
foo(a)
{
return(1234);
}
bar(a)
{
return(5678);
}

--
mitc...@mdi.com (Bill Mitchell)

Bill Mitchell

unread,
Sep 24, 1991, 9:01:36 PM9/24/91
to
In article <55...@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!

--
mitc...@mdi.com (Bill Mitchell)

William Spitzak

unread,
Sep 26, 1991, 2:00:42 AM9/26/91
to
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:

extern errorcode sysfunction(int *returnvalue,args...);

...
int junk;
if (sysfunction(&junk,1,2,3),junk) {...

Bill Spitzak, a disillusioned hacker.

Mike Sangrey

unread,
Sep 25, 1991, 6:05:38 PM9/25/91
to
ro...@itx.isc.com (Rob Tulloh) writes:

spco...@uokmax.ecn.uoknor.edu (Steve Coltrin) writes:

>la...@lobster.cps.msu.edu (Mark M Lacey) writes:

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 |

Johan Bengtsson

unread,
Sep 26, 1991, 8:37:48 AM9/26/91
to
mitc...@MDI.COM (Bill Mitchell) writes:
> >dwa...@stratsft.uucp (Dwayne Bailey) writes:
> >
> >>#define mymac(a) (foo(a), bar(a))
> >
> >>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 |
-----------------------------------------------------------------------------

Amanda Walker

unread,
Sep 26, 1991, 6:40:16 PM9/26/91
to
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.

David Fox

unread,
Sep 26, 1991, 2:17:00 PM9/26/91
to
In article <1991Sep25.0...@MDI.COM> mitc...@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.

-david

house ron

unread,
Sep 27, 1991, 8:19:41 AM9/27/91
to
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:

while(i++<j) {
x=some_action(i),
y=other_result(i);
do_something(x,y),
etc, etc;
}
the_next_bit();

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)

John Baldwin

unread,
Sep 26, 1991, 12:47:08 PM9/26/91
to
In article <1991Sep25.0...@MDI.COM>
mitc...@MDI.COM (Bill Mitchell) writes:
< In article <55...@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

Christopher R Volpe

unread,
Sep 30, 1991, 8:34:37 AM9/30/91
to
In article <1991Sep26....@visix.com>, ama...@visix.com (Amanda

Walker) writes:
|>
|>#define DEBUG_MSG !debug ? 0 : printf

Now that's one macro definition that you better *not* wrap parentheses
around!

|>Twisted, but it works...
|>
|>Amanda Walker ama...@visix.com
|>Visix Software Inc. ...!uunet!visix!amanda

==================
Chris Volpe
G.E. Corporate R&D
vol...@crd.ge.com

Geoff Clare

unread,
Sep 30, 1991, 12:49:09 PM9/30/91
to

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

Tim McDaniel

unread,
Oct 9, 1991, 2:52:06 PM10/9/91
to
In article <33...@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: mcda...@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel

alexis...@gmail.com

unread,
Jun 3, 2015, 2:35:16 PM6/3/15
to
On Wednesday, September 25th 1991 09:34:32 UTC-4, John F. Woods wrote :

> 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.

Hey John, did you know that this quote would become so popular more than twenty years later ? YOU WERE RIGHT ALL ALONG !!!
Reply all
Reply to author
Forward
0 new messages