What does this code mean???

I am reading the code of a program from the examples, but really don't understand this one........ int i,j; ..................................................... while (scanf("%d",&i),j) { ........................................ } So I think the question should become, how does the compiler evaluate the expression, (int i,int j)?? (am I right?? 'cause scanf function returns an integer as I know)

Mars wrote: > I am reading the code of a program from the examples, but really don't > understand this one........ > > int i,j; > > .................................................... > > while (scanf("%d",&i),j) > { > ....................................... > } > > So I think the question should become, > how does the compiler evaluate the expression, (int i,int j)?? That's a typical application of the comma-operator, look it up in your books. > (am I right?? 'cause scanf function returns an integer as I know) You really should not need to ask what scanf() returns and what that returnvalue means, you should know where to find that info. You are right with your assumption though. Uli

Mars wrote: > I am reading the code of a program from the examples, but really don't > understand this one........ > > int i,j; > > .................................................... > > while (scanf("%d",&i),j) > { > ....................................... > } Break it down like this: scanf("%d", &i), j The value returned by scanf is discarded and the whole expression evaluates to the value of j. A sequence point occurs at the comma. (See Annex C of the C Standard). The loop is reading in values and will continue executing while j is not 0. As an example, see what this does: /* comma.c */ #include <stdio.h> int main (void) { int a, b = 6; int ret; ret = (a = 5, b); printf ("a: %d; ret: %d\n", a, ret); return 0; } Regards, Jonathan. -- "We must do something. This is something. Therefore, we must do this." - Keith Thompson

On Sun, 30 Jan 2005 19:20:52 +0800, Mars <Mars@Mars> wrote: >I am reading the code of a program from the examples, but really don't >understand this one........ > >int i,j; > >.................................................... > >while (scanf("%d",&i),j) >{ >....................................... >} It's the comma operator. The call to scanf() occurs as part of the loop but occurs before evaluating the end condition. It's the same as either: scanf("%d",&i); while (j) { /*....................................... */ scanf("%d",&i); } or: while (1) { scanf("%d",&i); if (!j) break; /*....................................... */ } Nick.

icic, thx~ Jonathan Burd mentioned: > Mars wrote: > >>I am reading the code of a program from the examples, but really don't >>understand this one........ >> >>int i,j; >> >>.................................................... >> >>while (scanf("%d",&i),j) >>{ >>....................................... >>} > > > Break it down like this: > > scanf("%d", &i), j > > The value returned by scanf is discarded and the whole expression > evaluates to the value of j. A sequence point occurs > at the comma. (See Annex C of the C Standard). > > The loop is reading in values and will continue executing > while j is not 0. > > As an example, see what this does: > > /* comma.c */ > #include <stdio.h> > > int > main (void) > { > int a, b = 6; > int ret; > > ret = (a = 5, b); > > printf ("a: %d; ret: %d\n", a, ret); > > return 0; > } > > Regards, > Jonathan. >

Thx~~ Nick Austin mentioned: > On Sun, 30 Jan 2005 19:20:52 +0800, Mars <Mars@Mars> wrote: > > >>I am reading the code of a program from the examples, but really don't >>understand this one........ >> >>int i,j; >> >>.................................................... >> >>while (scanf("%d",&i),j) >>{ >>....................................... >>} > > > It's the comma operator. The call to scanf() occurs as part of > the loop but occurs before evaluating the end condition. > > It's the same as either: > > scanf("%d",&i); > while (j) > { > /*....................................... */ > scanf("%d",&i); > } > > or: > > while (1) > { > scanf("%d",&i); > if (!j) > break; > /*....................................... */ > } > > Nick. >

Mars wrote: > icic, thx~ <snip> Please do not top-post in c.l.c. Top-posting blurs the context and makes it difficult to see what you are replying to. Regards, Jonathan. -- "We must do something. This is something. Therefore, we must do this." - Keith Thompson

Jonathan Burd <jonathan.burd@REMOVEMEgmail.com> wrote: > Mars wrote: > > while (scanf("%d",&i),j) > Break it down like this: > > scanf("%d", &i), j > > The value returned by scanf is discarded and the whole expression > evaluates to the value of j. A sequence point occurs > at the comma. (See Annex C of the C Standard). > > The loop is reading in values and will continue executing > while j is not 0. True, but I must say that this is an inadvisable way of using the comma operator. The scanf() call has nothing to do with whether or not the loop continues at all. This use of the comma is mere obfuscation. Richard

"Richard Bos" <rlb@hoekstra-uitgeverij.nl> schreef in bericht news:41fdeebe.254654545@news.individual.net... > True, but I must say that this is an inadvisable way of using the comma > operator. The scanf() call has nothing to do with whether or not the > loop continues at all. This use of the comma is mere obfuscation. That's your opinion of course. I like this style because the return value of scanf is often ignored anyway and you dont need to put in 2 calls to scanf as in: scanf(); while(j) { scanf(); }

On Mon, 31 Jan 2005 14:49:30 +0100, Serv� La wrote: > > "Richard Bos" <rlb@hoekstra-uitgeverij.nl> schreef in bericht > news:41fdeebe.254654545@news.individual.net... > >> True, but I must say that this is an inadvisable way of using the comma >> operator. The scanf() call has nothing to do with whether or not the >> loop continues at all. This use of the comma is mere obfuscation. > > That's your opinion of course. I like this style because the return value of > scanf is often ignored anyway Unfortunately true. Consider however there are very few situations where ignoring the return value of scanf() isn't a bug. Lawrence

Serv=E9 La wrote: > "Richard Bos" <rlb@hoekstra-uitgeverij.nl> schreef in bericht > news:41fdeebe.254654545@news.individual.net... >=20 >=20 >>True, but I must say that this is an inadvisable way of using the comma= >>operator. The scanf() call has nothing to do with whether or not the >>loop continues at all. This use of the comma is mere obfuscation. >=20 >=20 > That's your opinion of course. I like this style because the return val= ue of > scanf is often ignored anyway [...] What else do you ignore? NULL values from malloc() and fopen()? Warning messages from compilers? STOP signs? Fire alarms? No wonder software sucks. --=20 Eric.Sosman@sun.com

Lawrence Kirby wrote: > .... snip ... > > Unfortunately true. Consider however there are very few situations > where ignoring the return value of scanf() isn't a bug. I rarely use scanf so am not sure, but are there any situations in which it isn't a bug? -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson

see the code below x=(scanf("%d",&i),j,k,l,......,z); /*x will hav the value of z*/ u should that the comma separated expressions are evaluated from Left to Right and thats why the whole expression i.e. x, woud have a value of the rightmost expression i.e. z now consider this example printf("here is a value : %d", ( 1,2,3,4,5,6,7,8,9)); output: here is a vlaue : 9 so now i think that the it is clear to u thanx :-)

On Mon, 31 Jan 2005 15:50:41 +0000, CBFalconer wrote: > Lawrence Kirby wrote: >> > ... snip ... >> >> Unfortunately true. Consider however there are very few situations >> where ignoring the return value of scanf() isn't a bug. > > I rarely use scanf so am not sure, but are there any situations in > which it isn't a bug? Only situations where you didn't care if the read operation failed or encountered end-of-file, and the scanf() just readss characters without writing values. scanf(fp, " ") to skip white-space perhaps in some odd circumstances. Not very likely but it is difficult to say that there is NO situation where this isn't a bug. Well actually easy to say, maybe I should and just wait for others to come up with the counterexamples. :-) Lawrence

"parser" <saleem.a.ansari@gmail.com> wrote: [ Please ditch Google Broken Beta or learn to use it to post properly, _with_ normal quoting. Also, learn to write grammatical English. You're nearly illegible. ] > see the code below > x=(scanf("%d",&i),j,k,l,......,z); /*x will hav the value of z*/ > > u should that the comma separated expressions are evaluated from Left > to Right and thats why the whole expression i.e. x, woud have a value > of the rightmost expression i.e. z No, that's not why. For example, the expressions separated by a string of && operators are _also_ evaluated from left to right, but the value of the whole expression is either 0 or 1, depending on any number of the expressions, no matter whether the relevant ones are 1, 3.14159265, &main, or any other non-zero value. Your conclusion is correct in so far that the Standard says of the , operator that - its operands are evaluated in the order left first, then right; - because of the way its syntax it specified, it is left-to-right associative (which, in conjunction with the above, also means that a string of expressions separated by commas is evaluated left to right); - the value and type of the whole expression are those of the right argument. However, the third requirement does not follow by necessity from the first two at all. Richard

On Tue, 01 Feb 2005 14:29:07 +0000, Lawrence Kirby <lknews@netactive.co.uk> wrote: > On Mon, 31 Jan 2005 15:50:41 +0000, CBFalconer wrote: > >> Lawrence Kirby wrote: >>> >> ... snip ... >>> >>> Unfortunately true. Consider however there are very few situations >>> where ignoring the return value of scanf() isn't a bug. >> >> I rarely use scanf so am not sure, but are there any situations in >> which it isn't a bug? > > Only situations where you didn't care if the read operation failed or > encountered end-of-file, and the scanf() just readss characters without > writing values. scanf(fp, " ") to skip white-space perhaps in some odd > circumstances. Not very likely but it is difficult to say that there > is NO situation where this isn't a bug. Well actually easy to say, maybe I > should and just wait for others to come up with the counterexamples. :-) I'm not aware of any for scanf, but sscanf can certainly be legitimately used without checking the return value, because it leaves its arguments alone if it has no data so they default to the latest value. Silly example: #include <stdio.h> int main(void) { char buff[256]; int x = 0; int y = 0; while (fgets(buff, 256, stdin)) { sscanf(buff, "%d%d", &x, &y); printf("%d + %d = %d\n", x, y, x+y); } return 0; } I suppose one could use something similar with scanf() and check feof() after each call. Chris C

"Eric Sosman" <eric.sosman@sun.com> schreef in bericht news:ctlio9$fmt$1@news1brm.Central.Sun.COM... >>True, but I must say that this is an inadvisable way of using the comma >>operator. The scanf() call has nothing to do with whether or not the >>loop continues at all. This use of the comma is mere obfuscation. > > > That's your opinion of course. I like this style because the return value of > scanf is often ignored anyway [...] What else do you ignore? NULL values from malloc() and fopen()? Warning messages from compilers? STOP signs? Fire alarms? As as advised in this group, scanf is best to be avoided except in quick test programs. I haven't seen a lot of error checking in that kind of programs.

"Serv� La" wrote: > .... snip ... > > As as advised in this group, scanf is best to be avoided except in > quick test programs. I haven't seen a lot of error checking in that > kind of programs. It can be quite useful if restricted to single operands, i.e.: if (1 == scanf("%?", &something)) usesomething; else failure; with %? standing for a suitable customization. Scanf will leave the terminating char. in the input stream, so you know that an input line has at least one unconsumed \n left. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer <cbfalconer@yahoo.com> writes: > "Serv� La" wrote: >> > ... snip ... >> >> As as advised in this group, scanf is best to be avoided except in >> quick test programs. I haven't seen a lot of error checking in that >> kind of programs. > > It can be quite useful if restricted to single operands, i.e.: > > if (1 == scanf("%?", &something)) usesomething; > else failure; > > with %? standing for a suitable customization. Scanf will leave > the terminating char. in the input stream, so you know that an > input line has at least one unconsumed \n left. One possible pitfall is that, for example, scanf("%d", &an_integer) skips leading whitespace, including newlines. If you use fgets() followed by sscanf(), a user who hits <return> (assuming interactive keyboard input) will get an error message. If you use scanf() directly, the user can hit <return> arbitrarily many times without getting any feedback. Whether this is a problem depends, of course, on the application. -- Keith Thompson (The_Other_Keith) kst-u@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.