By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,332 Members | 1,505 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,332 IT Pros & Developers. It's quick & easy.

Sequence point at comma?

P: n/a

I know there's a sequence point at a comma, e.g.:

int main(void)
{
int a = 1;
a++, ++a, a *= 3, a <<= 4; /* Perfectly okay */
}
But does that also include the commas which separate function arguments? Is
the following code broken?

void Func( int, int, int, int );

int main(void)
{
int a = 1;

Func( a++, ++a, a *= 3, a <<= 4 );
}
--

Frederick Gotham
Jun 28 '06 #1
Share this Question
Share on Google+
17 Replies


P: n/a
Frederick Gotham schrieb:
I know there's a sequence point at a comma, e.g.:

int main(void)
{
int a = 1;
a++, ++a, a *= 3, a <<= 4; /* Perfectly okay */
}
But does that also include the commas which separate function arguments?
No.
Is
the following code broken?

void Func( int, int, int, int );

int main(void)
{
int a = 1;

Func( a++, ++a, a *= 3, a <<= 4 );
}


Yes.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Jun 28 '06 #2

P: n/a
On Wed, 28 Jun 2006 16:12:36 GMT, Frederick Gotham
<fg*******@SPAM.com> wrote:

I know there's a sequence point at a comma, e.g.:

int main(void)
{
int a = 1;
a++, ++a, a *= 3, a <<= 4; /* Perfectly okay */
}
But does that also include the commas which separate function arguments? Is
the following code broken?

void Func( int, int, int, int );

int main(void)
{
int a = 1;

Func( a++, ++a, a *= 3, a <<= 4 );
}


Yes, it is broken:

ISO/IEC 9899:1999

6.5.2.2 Function calls
Constraints
....
10 The order of evaluation of the function designator, the actual
arguments, and subexpressions within the actual arguments is
unspecified, but there is a sequence point before the actual call.
Jun 28 '06 #3

P: n/a
Frederick Gotham wrote:
I know there's a sequence point at a comma, e.g.:

int main(void)
{
int a = 1;
a++, ++a, a *= 3, a <<= 4; /* Perfectly okay */
}
Yes. Not only is there a sequence point between each operation but the
order of evaluation is guaranteed to be from left to right, the result
of which will have the type and valud of the rightmost expression.
But does that also include the commas which separate function arguments?
No, commas seperating function arguments or list items are not the
comma operator and do not introduce a sequence point.
Is the following code broken?
Yes.
void Func( int, int, int, int );

int main(void)
{
int a = 1;

Func( a++, ++a, a *= 3, a <<= 4 );
}


The function arguments may be evaluated in any order and since there is
no sequence point between the modifications of "a" the behavior is
undefined.

Robert Gamble

Jun 28 '06 #4

P: n/a

Frederick Gotham wrote:
a++, ++a, a *= 3, a <<= 4; /* Perfectly okay */


There is a difference between "it'll work" and "Perfectly okay".

Good: knowing about sequence points

Bad: Thinking the coma operator is a license to write anything.

Tom

Jun 28 '06 #5

P: n/a
On Wed, 28 Jun 2006 16:12:36 GMT, Frederick Gotham
<fg*******@SPAM.com> wrote:

I know there's a sequence point at a comma, e.g.:
No, there's a sequence point at comma operators, not at commas in
general.
int main(void)
{
int a = 1;
a++, ++a, a *= 3, a <<= 4; /* Perfectly okay */
}
But does that also include the commas which separate function arguments? Is
the following code broken?

void Func( int, int, int, int );

int main(void)
{
int a = 1;

Func( a++, ++a, a *= 3, a <<= 4 );
}


--
Al Balmer
Sun City, AZ
Jun 28 '06 #6

P: n/a
"Tom St Denis" <to********@gmail.com> writes:
Frederick Gotham wrote:
a++, ++a, a *= 3, a <<= 4; /* Perfectly okay */


There is a difference between "it'll work" and "Perfectly okay".

Good: knowing about sequence points

Bad: Thinking the coma operator is a license to write anything.


The coma operator is a license to take a very long nap.

Getting back to the comma operator ... 8-)}

The above code fragment is ok for illustrating the point. It should
not appear in actual code. A better way to write it would be:

a = ((a + 2) * 3) << 4;

More generally, if the subexpressions can't be combined like this,
there's no good reason to use a comma operator rather than separate
statements:

a++;
++b;
c *= 3;
d <<= 4;

*unless* the whole thing is part of a macro definition that needs to
expand to an expression rather than a sequence of statements.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 28 '06 #7

P: n/a

Keith Thompson wrote:
"Tom St Denis" <to********@gmail.comwrites:
Frederick Gotham wrote:
a++, ++a, a *= 3, a <<= 4; /* Perfectly okay */
There is a difference between "it'll work" and "Perfectly okay".

Good: knowing about sequence points

Bad: Thinking the coma operator is a license to write anything.

The coma operator is a license to take a very long nap.

Getting back to the comma operator ... 8-)}

The above code fragment is ok for illustrating the point. It should
not appear in actual code. A better way to write it would be:

a = ((a + 2) * 3) << 4;

More generally, if the subexpressions can't be combined like this,
there's no good reason to use a comma operator rather than separate
statements:

a++;
++b;
c *= 3;
d <<= 4;

*unless* the whole thing is part of a macro definition that needs to
expand to an expression rather than a sequence of statements.
The statement that "there is no good reason" is a
little strong. I expect you've seen otherwise
reasonable code that puts related assignments on the
same line, using comma operators to separate them:

p++, q++;

Depending on circumstances, it can help code clarity
to do so. cf Fred Brooks, "The Mythical Man-Month".

Jul 18 '06 #8

P: n/a
en******@yahoo.com writes:
Keith Thompson wrote:
[...]
>More generally, if the subexpressions can't be combined like this,
there's no good reason to use a comma operator rather than separate
statements:

a++;
++b;
c *= 3;
d <<= 4;

*unless* the whole thing is part of a macro definition that needs to
expand to an expression rather than a sequence of statements.

The statement that "there is no good reason" is a
little strong. I expect you've seen otherwise
reasonable code that puts related assignments on the
same line, using comma operators to separate them:

p++, q++;

Depending on circumstances, it can help code clarity
to do so. cf Fred Brooks, "The Mythical Man-Month".
If I felt the need to put those two expressions on the same line, I'd
probably write

p++; q++;

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 18 '06 #9

P: n/a

Keith Thompson wrote:
en******@yahoo.com writes:
Keith Thompson wrote:
[...]
More generally, if the subexpressions can't be combined like this,
there's no good reason to use a comma operator rather than separate
statements:

a++;
++b;
c *= 3;
d <<= 4;

*unless* the whole thing is part of a macro definition that needs to
expand to an expression rather than a sequence of statements.
The statement that "there is no good reason" is a
little strong. I expect you've seen otherwise
reasonable code that puts related assignments on the
same line, using comma operators to separate them:

p++, q++;

Depending on circumstances, it can help code clarity
to do so. cf Fred Brooks, "The Mythical Man-Month".

If I felt the need to put those two expressions on the same line, I'd
probably write

p++; q++;
Yes that's another way of doing it. I usually
follow the rule of no more than one statement
on a line, which fits nicely with how comma
works in C.

Jul 18 '06 #10

P: n/a
Keith Thompson posted:
>If I felt the need to put those two expressions on the same line, I'd
probably write

p++; q++;

If I have a very simple if-statement or loop, I might write:
if(expr) ++p,++q;

do ++p,++q;
while (expr);
--

Frederick Gotham
Jul 18 '06 #11

P: n/a

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:uH*******************@news.indigo.ie...
Keith Thompson posted:
>>If I felt the need to put those two expressions on the same line, I'd
probably write

p++; q++;


If I have a very simple if-statement or loop, I might write:
if(expr) ++p,++q;

do ++p,++q;
while (expr);

--

Frederick Gotham
I find those constructs to be inherently dangerous -
someone who dislikes using comma operators may
later come along and replace the commas
with semicolons, and bang! it's broken.

My personal coding standard is to ALWAYS use
braces in if, for, do, and while expressions.Even:
if (something) {return;}

--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project
Jul 18 '06 #12

P: n/a
On Tue, 18 Jul 2006 09:13:15 GMT, Keith Thompson <ks***@mib.org>
wrote:
>en******@yahoo.com writes:
>Keith Thompson wrote:
[...]
>>More generally, if the subexpressions can't be combined like this,
there's no good reason to use a comma operator rather than separate
statements:

a++;
++b;
c *= 3;
d <<= 4;

*unless* the whole thing is part of a macro definition that needs to
expand to an expression rather than a sequence of statements.

The statement that "there is no good reason" is a
little strong. I expect you've seen otherwise
reasonable code that puts related assignments on the
same line, using comma operators to separate them:

p++, q++;

Depending on circumstances, it can help code clarity
to do so. cf Fred Brooks, "The Mythical Man-Month".

If I felt the need to put those two expressions on the same line, I'd
probably write

p++; q++;
Not where I've usually seen such things - as the third expression in a
for statement.

--
Al Balmer
Sun City, AZ
Jul 18 '06 #13

P: n/a
Al Balmer <al******@att.netwrites:
On Tue, 18 Jul 2006 09:13:15 GMT, Keith Thompson <ks***@mib.org>
wrote:
>>en******@yahoo.com writes:
>>Keith Thompson wrote:
[...]
>>>More generally, if the subexpressions can't be combined like this,
there's no good reason to use a comma operator rather than separate
statements:

a++;
++b;
c *= 3;
d <<= 4;

*unless* the whole thing is part of a macro definition that needs to
expand to an expression rather than a sequence of statements.

The statement that "there is no good reason" is a
little strong. I expect you've seen otherwise
reasonable code that puts related assignments on the
same line, using comma operators to separate them:

p++, q++;

Depending on circumstances, it can help code clarity
to do so. cf Fred Brooks, "The Mythical Man-Month".

If I felt the need to put those two expressions on the same line, I'd
probably write

p++; q++;

Not where I've usually seen such things - as the third expression in a
for statement.
Yes, that's another reasonable use for the comma operator, and one
that I forgot to mention.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 18 '06 #14

P: n/a
Keith Thompson wrote:
en******@yahoo.com writes:
>Keith Thompson wrote:
[...]
>>More generally, if the subexpressions can't be combined like this,
there's no good reason to use a comma operator rather than separate
statements:

a++;
++b;
c *= 3;
d <<= 4;

*unless* the whole thing is part of a macro definition that needs to
expand to an expression rather than a sequence of statements.
The statement that "there is no good reason" is a
little strong. I expect you've seen otherwise
reasonable code that puts related assignments on the
same line, using comma operators to separate them:

p++, q++;

Depending on circumstances, it can help code clarity
to do so. cf Fred Brooks, "The Mythical Man-Month".

If I felt the need to put those two expressions on the same line, I'd
probably write

p++; q++;
The only place I use the comma operator is where two expressions are to
form a single statement.

char *fn = "filename";

if ((fp = fopen(fn, "r")) == NULL)
fprintf(stderr, "Can't open %s\n", fn), exit(EXIT_FAILURE);

Avoiding the comma will create two statements and cost a pair of curlies
as well.

if ((fp = fopen(fn, "r")) == NULL) {
fprintf(stderr, "Can't open %s\n", fn);
exit(EXIT_FAILURE);
}

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jul 18 '06 #15

P: n/a
Joe Wright wrote:
The only place I use the comma operator
is where two expressions are to
form a single statement.

char *fn = "filename";

if ((fp = fopen(fn, "r")) == NULL)
fprintf(stderr, "Can't open %s\n", fn), exit(EXIT_FAILURE);

Avoiding the comma will create two statements
and cost a pair of curlies as well.

if ((fp = fopen(fn, "r")) == NULL) {
fprintf(stderr, "Can't open %s\n", fn);
exit(EXIT_FAILURE);
}
I would write it the second way
without even thinking about it.

I propbably don't fully appreciate
the cost of a pair of curlies.

--
pete
Jul 18 '06 #16

P: n/a
Joe Wright <jo********@comcast.netwrites:
Keith Thompson wrote:
>en******@yahoo.com writes:
>>Keith Thompson wrote:
[...]
>>>More generally, if the subexpressions can't be combined like this,
there's no good reason to use a comma operator rather than separate
statements:

a++;
++b;
c *= 3;
d <<= 4;

*unless* the whole thing is part of a macro definition that needs to
expand to an expression rather than a sequence of statements.
The statement that "there is no good reason" is a
little strong. I expect you've seen otherwise
reasonable code that puts related assignments on the
same line, using comma operators to separate them:

p++, q++;

Depending on circumstances, it can help code clarity
to do so. cf Fred Brooks, "The Mythical Man-Month".
If I felt the need to put those two expressions on the same line, I'd
probably write
p++; q++;
The only place I use the comma operator is where two expressions are
to form a single statement.

char *fn = "filename";

if ((fp = fopen(fn, "r")) == NULL)
fprintf(stderr, "Can't open %s\n", fn), exit(EXIT_FAILURE);

Avoiding the comma will create two statements and cost a pair of
curlies as well.

if ((fp = fopen(fn, "r")) == NULL) {
fprintf(stderr, "Can't open %s\n", fn);
exit(EXIT_FAILURE);
}
Yes, at the terrible expense of code that's much clearer and easier to
read.

It wouldn't even occur to me to use a comma operator in that case.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 19 '06 #17

P: n/a
Keith Thompson wrote:
Joe Wright <jo********@comcast.netwrites:
>Keith Thompson wrote:
>>en******@yahoo.com writes:
Keith Thompson wrote:
[...]
More generally, if the subexpressions can't be combined like this,
there's no good reason to use a comma operator rather than separate
statements:
>
a++;
++b;
c *= 3;
d <<= 4;
>
*unless* the whole thing is part of a macro definition that needs to
expand to an expression rather than a sequence of statements.
The statement that "there is no good reason" is a
little strong. I expect you've seen otherwise
reasonable code that puts related assignments on the
same line, using comma operators to separate them:

p++, q++;

Depending on circumstances, it can help code clarity
to do so. cf Fred Brooks, "The Mythical Man-Month".
If I felt the need to put those two expressions on the same line, I'd
probably write
p++; q++;
The only place I use the comma operator is where two expressions are
to form a single statement.

char *fn = "filename";

if ((fp = fopen(fn, "r")) == NULL)
fprintf(stderr, "Can't open %s\n", fn), exit(EXIT_FAILURE);

Avoiding the comma will create two statements and cost a pair of
curlies as well.

if ((fp = fopen(fn, "r")) == NULL) {
fprintf(stderr, "Can't open %s\n", fn);
exit(EXIT_FAILURE);
}

Yes, at the terrible expense of code that's much clearer and easier to
read.

It wouldn't even occur to me to use a comma operator in that case.
A chacun son gout. I kinda like it. :-)

Your disapproval is noted. And pete's too.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jul 19 '06 #18

This discussion thread is closed

Replies have been disabled for this discussion.