Unexpected output

[Paul N]

     C has two distinct uses for the comma: as an operator, and as
a separator.  The comma operator involves a defined order and a
sequence point: `f = x,y' means "first evaluate x and ignore the
value, sequence point, then evaluate y and yield its value, that
value is assigned to f."

Just to be picky, won't that expression actually assign x to f, as the
= operator has a higher precedence than the , operator? (And yes, I
know the standard doesn't actually call it precedence.)

 

[August Karlstrom]

Hello,

Following is a simple program:

#include<stdio.h>

int main(void) {
int i = 0, j, k;
j = k = 2;

printf("%d %d\n", i=+j, i=-j);

return 0;
}

The output is
2 2

Shouldn't the second expression be -2 rather than 2? I'm confused.
Your insights pls. Thanks!

One obvious insight is that it's best to avoid side effects in
expressions if possible.


August

 

[Eric Sosman]

Just to be picky, won't that expression actually assign x to f, as the
= operator has a higher precedence than the , operator? (And yes, I
know the standard doesn't actually call it precedence.)

Oops! Serves me right for editing my example ("for clarity," of
course) after writing it -- and after ceasing to think ...

 

[Ben Bacarisse]

One obvious insight is that it's best to avoid side effects in
expressions if possible.

The devil is in the detail. You presumably think that x = 1; is OK so
what about x++? How do you feel about *cp++ = 0? Maybe *dp++ = *s++?

At some stage most C programmers need to know what's permitted and what
is not. They may never need to know the rule itself, but they will
probably come up with the notion that, if an expression can yield two
different results with different (permitted) evaluation orders, then
there be dragons. This has the advantage of focusing on possible
evaluation orders which is an essential part of C programming.
printf("%d %d", f(), g()) may not be undefined, but the programmer would
be well advised to know that the order of execution is not specified.

 

[August Karlstrom]

The devil is in the detail. You presumably think that x = 1; is OK so
what about x++?

Both `x = 1;' and `x++;' are atomic statements (they cannot be
decomposed into some other sequence of simpler statements), so yes they
are certainly OK.

How do you feel about *cp++ = 0? Maybe *dp++ = *s++?

I feel that there is too much going on in each of these. Of course this
is to some degree a matter of preference but personally I don't think
these statements communicate very well and I think they are inherently ugly.

At some stage most C programmers need to know what's permitted and what
is not.

Yes, but if you write new code and adhere to the KISS principle you
don't need to bother with a lot of C's subtleties.


August

 

[Ben Bacarisse]

Both `x = 1;' and `x++;' are atomic statements (they cannot be
decomposed into some other sequence of simpler statements), so yes
they are certainly OK.


I feel that there is too much going on in each of these. Of course
this is to some degree a matter of preference but personally I don't
think these statements communicate very well and I think they are
inherently ugly.

That's a logical place to draw the line, but I can't go along with it.
I can't say why except that is seems un-C-like to reject them. There's
no logic to my point of view -- it seems to be no more that a matter to
taste than anything else.

<snip>

 

[Seebs]

Depends on compiler/optimizer implementation.

Whether or not it is undefined does not depend on that. What you get does.

-s

 

[Phil Carmody]

As Joe Pfeiffer points out, that's not quite correct.


Grab a copy of the latest C99 draft from

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

and read section J.2.

This might be a better introduction, to lead up to the formality
of the official docs:
http://c-faq.com/expr/index.html

Phil

 

[August Karlstrom]

That's a logical place to draw the line, but I can't go along with it.
I can't say why except that is seems un-C-like to reject them. There's
no logic to my point of view -- it seems to be no more that a matter to
taste than anything else.

The question is, when does a statement become too complex? Programming
should be about reducing complexity, not adding to it. That's why
structured programming, user defined functions and so on was invented. I
myself prefer to focus my energy on algorithms rather than on
intricacies of the programming language.

Also, a complex expression with multiple side effects in a statement
does not make the algorithm any simpler - only shorter, but not simpler.
Moreover, it is only shorter notation-wise; if your read such a
statement aloud or write it in plain English it is not shorter. It just
makes for a longer and more convoluted sentence.

So, although writing convoluted code is a part of the C tradition, if
you can resist the temptation of saving a few keystrokes you will
probably save some maintenance time in the future. As we all know, C
does not enforce or advocate any particular coding style. On the
contrary, giving the programmer maximum freedom, and that includes the
freedom to write clear code, is the spirit of C.


August