Plz explain me the following code

Discussion in 'C Programming' started by manish sahu, Sep 19, 2009.

  1. manish sahu

    manish sahu Guest

    plz tell me how this code is working and what would be the the o/p
    1)

    {
    int x=20,y=35;
    x = y++ + x++;
    y = ++y + ++x;
    printf("%d %dn",x,y);
    }


    2)
    {
    int x=5;
    printf("%d %d %dn",x,x<<2,x>>2);
    }
    Thankyou
     
    manish sahu, Sep 19, 2009
    #1
    1. Advertising

  2. On 19 Sep, 17:24, manish sahu <> wrote:

    > plz tell me how this code is working and what would be the the o/p
    > 1)
    >
    > {
    > int x=20,y=35;
    > x = y++ + x++;


    the C standard does not define the behaviour of a program like
    this. Anything like
    i = i++;
    exhibits undefined behaviour. Dig out the comp.lang.c FAQ for details

    > y = ++y + ++x;
    > printf("%d %dn",x,y);
    >
    > }
    >
    > 2)
    > {
    > int x=5;
    > printf("%d %d %dn",x,x<<2,x>>2);}


    why don't you just run the program? Look in your textbook
    to find out what << and >> do
     
    Nick Keighley, Sep 19, 2009
    #2
    1. Advertising

  3. manish sahu

    Seebs Guest

    On 2009-09-19, manish sahu <> wrote:
    > plz tell me how this code is working and what would be the the o/p
    > 1)
    >
    > {
    > int x=20,y=35;
    > x = y++ + x++;
    > y = ++y + ++x;
    > printf("%d %dn",x,y);
    > }


    This could do just about anything; it's undefined behavior and there is no
    realistic way to determine what it "should" produce.

    > 2)
    > {
    > int x=5;
    > printf("%d %d %dn",x,x<<2,x>>2);
    > }


    This one is well-defined and requires no explanation.

    -s
    --
    Copyright 2009, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Sep 20, 2009
    #3
  4. manish sahu

    manish sahu Guest

    On Sep 19, 4:59 pm, Seebs <> wrote:
    > On 2009-09-19, manish sahu <> wrote:
    >
    > > plz tell me how this code is working and what would be the the o/p
    > > 1)

    >
    > > {
    > > int x=20,y=35;
    > > x = y++ + x++;
    > > y = ++y + ++x;
    > > printf("%d %dn",x,y);
    > > }

    >
    > This could do just about anything; it's undefined behavior and there is no
    > realistic way to determine what it "should" produce.
    >
    > > 2)
    > > {
    > > int x=5;
    > > printf("%d %d %dn",x,x<<2,x>>2);
    > > }

    >
    > This one is well-defined and requires no explanation.
    >
    > -s
    > --
    > Copyright 2009, all wrongs reversed.  Peter Seebach / ://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!


    Thankyou dear
     
    manish sahu, Sep 21, 2009
    #4
  5. On Sep 20, 9:59 am, Seebs <> wrote:
    > On 2009-09-19, manish sahu <> wrote:
    > > int x=5;
    > > printf("%d %d %dn",x,x<<2,x>>2);
    > > }

    >
    > This one is well-defined and requires no explanation.


    Whether a text line requires a terminating new-line is
    implementation defined. There can be practical consequences
    to leaving it off. [e.g. on old line printers.]

    --
    Peter
     
    Peter Nilsson, Sep 22, 2009
    #5
  6. manish sahu

    Ben Pfaff Guest

    Peter Nilsson <> writes:

    > On Sep 20, 9:59 am, Seebs <> wrote:
    >> On 2009-09-19, manish sahu <> wrote:
    >> > int x=5;
    >> > printf("%d %d %dn",x,x<<2,x>>2);
    >> > }

    >>
    >> This one is well-defined and requires no explanation.

    >
    > Whether a text line requires a terminating new-line is
    > implementation defined. There can be practical consequences
    > to leaving it off. [e.g. on old line printers.]


    The "n" is there, I think that manish just left off the \ as a
    typo.
    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
     
    Ben Pfaff, Sep 22, 2009
    #6
  7. Peter Nilsson <> writes:
    > On Sep 20, 9:59 am, Seebs <> wrote:
    >> On 2009-09-19, manish sahu <> wrote:
    >> > int x=5;
    >> > printf("%d %d %dn",x,x<<2,x>>2);
    >> > }

    >>
    >> This one is well-defined and requires no explanation.

    >
    > Whether a text line requires a terminating new-line is
    > implementation defined. There can be practical consequences
    > to leaving it off. [e.g. on old line printers.]


    "n" was almost certainly a typo for "\n".

    It's not clear that the output produced by the printf call is going to
    be the last line of the program's output. The posted code was just a
    single compound statement. It was probably intended to be the body of
    main(), but as long as we're not making assumptions ...

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 22, 2009
    #7
  8. On Sep 19, 6:24 pm, manish sahu <> wrote:
    > plz tell me how this code is working and what would be the the o/p
    > 1)
    >
    > {
    > int x=20,y=35;
    > x = y++ + x++;
    > y = ++y + ++x;
    > printf("%d %dn",x,y);
    >
    > }

    x is set to 20 and y is set to 35.
    in the next line you make x a result of 20+35 and THEN you increase
    both x and y. It means x should be 56 and y 35.
    Then you increase x (57) and y (36) and y = y + x will make y to be
    set to 93.
    But as my colleagues here said, it is compiler dependent (this code
    can be just junk)

    >
    > 2)
    > {
    > int x=5;
    > printf("%d %d %dn",x,x<<2,x>>2);}
    >
    > Thankyou

    Man, find out something about binary shifts by yourself :).
     
    Processor-Dev1l, Sep 22, 2009
    #8
  9. On Sep 22, 8:10 am, Processor-Dev1l <> wrote:
    > On Sep 19, 6:24 pm, manish sahu <> wrote:> plz tell me how this code is working and what would be the the o/p
    > > 1)

    >
    > > {
    > > int x=20,y=35;
    > > x = y++ + x++;
    > > y = ++y + ++x;
    > > printf("%d %dn",x,y);

    >
    > > }

    >
    > x is set to 20 and y is set to 35.
    > in the next line you make x a result of 20+35 and THEN you increase
    > both x and y. It means x should be 56 and y 35.
    > Then you increase x (57) and y (36) and y = y + x will make y to be
    > set to 93.
    > But as my colleagues here said, it is compiler dependent (this code
    > can be just junk)

    Correction here:
    > x is set to 20 and y is set to 35.
    > in the next line you make x a result of 20+35 and THEN you increase
    > both x and y. It means x should be 56 and y 36.
    > Then you increase x (57) and y (37) and y = y + x will make y to be
    > set to 94.
    > But as my colleagues here said, it is compiler dependent (this code
    > can be just junk)




    >
    >
    >
    > > 2)
    > > {
    > > int x=5;
    > > printf("%d %d %dn",x,x<<2,x>>2);}

    >
    > > Thankyou

    >
    > Man, find out something about binary shifts by yourself :).


    Sorry for typo...
     
    Processor-Dev1l, Sep 22, 2009
    #9
  10. Processor-Dev1l <> writes:
    > On Sep 19, 6:24 pm, manish sahu <> wrote:
    >> plz tell me how this code is working and what would be the the o/p
    >> 1)
    >>
    >> {
    >> int x=20,y=35;
    >> x = y++ + x++;
    >> y = ++y + ++x;
    >> printf("%d %dn",x,y);
    >>
    >> }

    > x is set to 20 and y is set to 35.
    > in the next line you make x a result of 20+35 and THEN you increase
    > both x and y. It means x should be 56 and y 35.
    > Then you increase x (57) and y (36) and y = y + x will make y to be
    > set to 93.
    > But as my colleagues here said, it is compiler dependent (this code
    > can be just junk)


    The behavior is undefined, as several posters have already pointed
    out.

    [snip]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 22, 2009
    #10
  11. On Sep 22, 8:21 am, Keith Thompson <> wrote:
    > Processor-Dev1l <> writes:
    > > On Sep 19, 6:24 pm, manish sahu <> wrote:
    > >> plz tell me how this code is working and what would be the the o/p
    > >> 1)

    >
    > >> {
    > >> int x=20,y=35;
    > >> x = y++ + x++;
    > >> y = ++y + ++x;
    > >> printf("%d %dn",x,y);

    >
    > >> }

    > > x is set to 20 and y is set to 35.
    > > in the next line you make x a result of 20+35 and THEN you increase
    > > both x and y. It means x should be 56 and y 35.
    > > Then you increase x (57) and y (36) and y = y + x will make y to be
    > > set to 93.
    > > But as my colleagues here said, it is compiler dependent (this code
    > > can be just junk)

    >
    > The behavior is undefined, as several posters have already pointed
    > out.
    >
    > [snip]
    >
    > --
    > Keith Thompson (The_Other_Keith)  <http://www.ghoti.net/~kst>
    > Nokia
    > "We must do something.  This is something.  Therefore, we must do this."
    >     -- Antony Jay and Jonathan Lynn, "Yes Minister"


    I just did a test on mainframe....

    $ cat ctest.c
    #include <stdio.h>

    int main(void)
    {
    int x;
    int y;

    x = 20;
    y = 35;

    x = y++ + x++;
    y = ++y + ++x;
    printf("x = %d, y = %d\n", x, y);

    return 0;
    }
    $ cc ctest.c
    IGD01008I ALLOCATION SET TO SCTEMPD M0610
    IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
    IGD01008I ALLOCATION SET TO SCTEMPD M0610
    IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
    $ ./a.out
    x = 57, y = 94
    $

    Everything what I want is someone with linux to try it with gcc
    compiler, that is
    all.
     
    Processor-Dev1l, Sep 22, 2009
    #11
  12. On 22 Sep, 08:29, Processor-Dev1l <> wrote:
    > On Sep 22, 8:21 am, Keith Thompson <> wrote:
    >
    >
    >
    >
    >
    > > Processor-Dev1l <> writes:
    > > > On Sep 19, 6:24 pm, manish sahu <> wrote:
    > > >> plz tell me how this code is working and what would be the the o/p
    > > >> 1)

    >
    > > >> {
    > > >> int x=20,y=35;
    > > >> x = y++ + x++;
    > > >> y = ++y + ++x;
    > > >> printf("%d %dn",x,y);

    >
    > > >> }
    > > > x is set to 20 and y is set to 35.
    > > > in the next line you make x a result of 20+35 and THEN you increase
    > > > both x and y. It means x should be 56 and y 35.
    > > > Then you increase x (57) and y (36) and y = y + x will make y to be
    > > > set to 93.
    > > > But as my colleagues here said, it is compiler dependent (this code
    > > > can be just junk)

    >
    > > The behavior is undefined, as several posters have already pointed
    > > out.

    >
    > > [snip]

    >
    > > --
    > > Keith Thompson (The_Other_Keith)  <http://www.ghoti.net/~kst>
    > > Nokia
    > > "We must do something.  This is something.  Therefore, we must do this."
    > >     -- Antony Jay and Jonathan Lynn, "Yes Minister"

    >
    > I just did a test on mainframe....
    >
    > $ cat ctest.c
    > #include <stdio.h>
    >
    > int main(void)
    > {
    >   int x;
    >   int y;
    >
    >   x = 20;
    >   y = 35;
    >
    >   x = y++ + x++;
    >   y = ++y + ++x;
    >   printf("x = %d, y = %d\n", x, y);
    >
    >   return 0;}
    >
    > $ cc ctest.c
    > IGD01008I ALLOCATION SET TO SCTEMPD M0610
    > IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
    > IGD01008I ALLOCATION SET TO SCTEMPD M0610
    > IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
    > $ ./a.out
    > x = 57, y = 94
    > $
    >
    > Everything what I want is someone with linux to try it with gcc
    > compiler, that is
    > all.


    why? It is Undefined Behaviour. Even changing the compiler
    optimisation
    level may change the result
     
    Nick Keighley, Sep 22, 2009
    #12
  13. On Sep 22, 10:13 am, Nick Keighley <>
    wrote:
    > On 22 Sep, 08:29, Processor-Dev1l <> wrote:
    >
    >
    >
    > > On Sep 22, 8:21 am, Keith Thompson <> wrote:

    >
    > > > Processor-Dev1l <> writes:
    > > > > On Sep 19, 6:24 pm, manish sahu <> wrote:
    > > > >> plz tell me how this code is working and what would be the the o/p
    > > > >> 1)

    >
    > > > >> {
    > > > >> int x=20,y=35;
    > > > >> x = y++ + x++;
    > > > >> y = ++y + ++x;
    > > > >> printf("%d %dn",x,y);

    >
    > > > >> }
    > > > > x is set to 20 and y is set to 35.
    > > > > in the next line you make x a result of 20+35 and THEN you increase
    > > > > both x and y. It means x should be 56 and y 35.
    > > > > Then you increase x (57) and y (36) and y = y + x will make y to be
    > > > > set to 93.
    > > > > But as my colleagues here said, it is compiler dependent (this code
    > > > > can be just junk)

    >
    > > > The behavior is undefined, as several posters have already pointed
    > > > out.

    >
    > > > [snip]

    >
    > > > --
    > > > Keith Thompson (The_Other_Keith)  <http://www.ghoti.net/~kst>
    > > > Nokia
    > > > "We must do something.  This is something.  Therefore, we must do this."
    > > >     -- Antony Jay and Jonathan Lynn, "Yes Minister"

    >
    > > I just did a test on mainframe....

    >
    > > $ cat ctest.c
    > > #include <stdio.h>

    >
    > > int main(void)
    > > {
    > >   int x;
    > >   int y;

    >
    > >   x = 20;
    > >   y = 35;

    >
    > >   x = y++ + x++;
    > >   y = ++y + ++x;
    > >   printf("x = %d, y = %d\n", x, y);

    >
    > >   return 0;}

    >
    > > $ cc ctest.c
    > > IGD01008I ALLOCATION SET TO SCTEMPD M0610
    > > IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
    > > IGD01008I ALLOCATION SET TO SCTEMPD M0610
    > > IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
    > > $ ./a.out
    > > x = 57, y = 94
    > > $

    >
    > > Everything what I want is someone with linux to try it with gcc
    > > compiler, that is
    > > all.

    >
    > why? It is Undefined Behaviour. Even changing the compiler
    > optimisation
    > level may change the result


    Why? Because it works on USS cc modified compiler and because I was
    trained to code this way :).
    I would do the test myself, but I have no access to common linux
    kernel now...
     
    Processor-Dev1l, Sep 22, 2009
    #13
  14. On Mon, 21 Sep 2009 23:10:20 -0700 (PDT), Processor-Dev1l
    <> wrote:

    >On Sep 19, 6:24 pm, manish sahu <> wrote:
    >> plz tell me how this code is working and what would be the the o/p
    >> 1)
    >>
    >> {
    >> int x=20,y=35;
    >> x = y++ + x++;
    >> y = ++y + ++x;
    >> printf("%d %dn",x,y);
    >>
    >> }

    >x is set to 20 and y is set to 35.
    >in the next line you make x a result of 20+35 and THEN you increase
    >both x and y. It means x should be 56 and y 35.


    There is no defined time when side effects will occur in relation to
    other events within the current interval between sequence points. What
    might be guaranteed is:
    1 - x++ is evaluated (yielding 20).
    2 - y++ is evaluated (yielding 35).
    3 - At some point during or after the evaluation of x++, the
    side effect of incrementing x occurs.
    4 - At some point during or after the evaluation of y++, the
    side effect of incrementing y occurs.
    5 - At some point after both x++ and y++ are evaluated, the +
    operand is evaluated (yielding 55).
    6 - At some point after the + operand is evaluated, the sum is
    stored in x.

    The ordering of 1 and 2 is unspecified. 1 must occur before 3, 2
    before 4, 1 and 2 before 5, and 5 before 6. Notice that there is no
    relationship in the sequencing of 3, 4, and 6. In any sequence where
    3 occurs before 6, x will end up containing 55. In any other
    sequence, x may end up containing 21 (since the value being
    incremented was determined to be 20) or may end up containing 56
    (since the current value of x is 55).

    Your subsequent test of a particular system proves nothing.

    >Then you increase x (57) and y (36) and y = y + x will make y to be
    >set to 93.


    But you don't know which of three plausible values x contains at this
    point. Since the behavior is explicitly undefined in the standard,
    there are a lot of other values x could contain or this statement
    might not even be executed.

    --
    Remove del for email
     
    Barry Schwarz, Sep 22, 2009
    #14
  15. manish sahu

    Seebs Guest

    On 2009-09-22, Processor-Dev1l <> wrote:
    > On Sep 19, 6:24 pm, manish sahu <> wrote:
    >> plz tell me how this code is working and what would be the the o/p
    >> 1)
    >>
    >> {
    >> int x=20,y=35;
    >> x = y++ + x++;
    >> y = ++y + ++x;
    >> printf("%d %dn",x,y);
    >>
    >> }

    > x is set to 20 and y is set to 35.
    > in the next line you make x a result of 20+35 and THEN you increase
    > both x and y. It means x should be 56 and y 35.


    Wrong.

    > But as my colleagues here said, it is compiler dependent (this code
    > can be just junk)


    Which is to say, the previous explanation is not correct, and has no meaning.

    -s
    --
    Copyright 2009, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Sep 22, 2009
    #15
  16. manish sahu

    Seebs Guest

    On 2009-09-22, Processor-Dev1l <> wrote:
    > Why? Because it works on USS cc modified compiler and because I was
    > trained to code this way :).


    Trained to try experiments that you can easily prove are meaningless and
    make proclamations about the results? That is a very strange way to be
    trained to code.

    -s
    --
    Copyright 2009, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Sep 22, 2009
    #16
  17. On Sep 22, 10:41 am, Barry Schwarz <> wrote:
    > On Mon, 21 Sep 2009 23:10:20 -0700 (PDT), Processor-Dev1l
    >
    > <> wrote:
    > >On Sep 19, 6:24 pm, manish sahu <> wrote:
    > >> plz tell me how this code is working and what would be the the o/p
    > >> 1)

    >
    > >> {
    > >> int x=20,y=35;
    > >> x = y++ + x++;
    > >> y = ++y + ++x;
    > >> printf("%d %dn",x,y);

    >
    > >> }

    > >x is set to 20 and y is set to 35.
    > >in the next line you make x a result of 20+35 and THEN you increase
    > >both x and y. It means x should be 56 and y 35.

    >
    > There is no defined time when side effects will occur in relation to
    > other events within the current interval between sequence points. What
    > might be guaranteed is:
    >         1 - x++ is evaluated (yielding 20).
    >         2 - y++ is evaluated (yielding 35).
    >         3 - At some point during or after the evaluation of x++, the
    > side effect of incrementing x occurs.
    >         4 - At some point during or after the evaluation of y++, the
    > side effect of incrementing y occurs.
    >         5 - At some point after both x++ and y++ are evaluated, the +
    > operand is evaluated (yielding 55).
    >         6 - At some point after the + operand is evaluated, the sum is
    > stored in x.
    >
    > The ordering of 1 and 2 is unspecified.  1 must occur before 3, 2
    > before 4, 1 and 2 before 5, and 5 before 6.  Notice that there is no
    > relationship in the sequencing of 3, 4, and 6.  In any sequence where
    > 3 occurs before 6, x will end up containing 55.  In any other
    > sequence, x may end up containing 21 (since the value being
    > incremented was determined to be 20) or may end up containing 56
    > (since the current value of x is 55).
    >
    > Your subsequent test of a particular system proves nothing.
    >
    > >Then you increase x (57) and y (36) and y = y + x will make y to be
    > >set to 93.

    >
    > But you don't know which of three plausible values x contains at this
    > point.  Since the behavior is explicitly undefined in the standard,
    > there are a lot of other values x could contain or this statement
    > might not even be executed.
    >
    > --
    > Remove del for email


    Congratz, yours was first acceptable answer :).

    Pitty is this style can be found even in some "ansi" C oriented books.
    It's really a pitty because what is written should be right...

    for manish:
    It is always better to use x++ on a standalone line except "for" cycle.
     
    Processor-Dev1l, Sep 22, 2009
    #17
  18. On Sep 19, 11:24 pm, manish sahu <> wrote:
    > plz tell me how this code is working ...
    > ...
    > x = y++ + x++;


    I have a sincere question for manish. And for the dozens of
    others who've asked almost the same question lately.

    Manish, why do you want to use this expression and, if
    there's no good reason, why do you particularly care
    what it does?

    I ask because even non-experts who know a little C can
    glance at the expression, realize that it at least *looks*
    potentially ambiguous, and *realize that the whole expression
    can easily be avoided*.

    It's fun to explore the nooks and crannies of a programming
    language, but why do so many beginners focus on the silly
    and useless?

    I'm reminded of a programmer (who didn't consider himself
    a beginner!) who looked over my shoulder as I proudly
    typed 'ls *.c' in my self-written image processing source
    directory. I had an adaptive histogram equalizer, advanced
    value-criterion filters and much more ... but he selected
    only the silly (and sillily-named) "kluge.c" for perusal!

    James
     
    James Dow Allen, Sep 22, 2009
    #18
  19. manish sahu

    Seebs Guest

    On 2009-09-22, James Dow Allen <> wrote:
    > Manish, why do you want to use this expression and, if
    > there's no good reason, why do you particularly care
    > what it does?


    I suspect it's a desire to understand how things work.

    > It's fun to explore the nooks and crannies of a programming
    > language, but why do so many beginners focus on the silly
    > and useless?


    Because edge conditions teach you more.

    > I'm reminded of a programmer (who didn't consider himself
    > a beginner!) who looked over my shoulder as I proudly
    > typed 'ls *.c' in my self-written image processing source
    > directory. I had an adaptive histogram equalizer, advanced
    > value-criterion filters and much more ... but he selected
    > only the silly (and sillily-named) "kluge.c" for perusal!


    That would be the most interesting to me, too! That would be the one
    that showed me where you had interesting things happening that you weren't
    quite sure about, probably.

    An adaptive histogram equalizer is probably boring. The curious hack
    you adopted because something was acting weird is probably interesting.

    -s
    --
    Copyright 2009, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Sep 22, 2009
    #19
  20. On Sep 22, 10:53 am, Seebs <> wrote:
    > On 2009-09-22, Processor-Dev1l <> wrote:
    >
    > > On Sep 19, 6:24 pm, manish sahu <> wrote:
    > >> plz tell me how this code is working and what would be the the o/p
    > >> 1)

    >
    > >> {
    > >> int x=20,y=35;
    > >> x = y++ + x++;
    > >> y = ++y + ++x;
    > >> printf("%d %dn",x,y);

    >
    > >> }

    > > x is set to 20 and y is set to 35.
    > > in the next line you make x a result of 20+35 and THEN you increase
    > > both x and y. It means x should be 56 and y 35.

    >
    > Wrong.

    Nice you are quoting my typo :).
    There is also a post where I repaired it :).
    You can also take a look at my test where I compiled and ran that
    code.
    If all you can do is to quote wrong post and to say only Wrong, you
    are just jerk :).

    Another thing that makes me thinking you are jerk is that you are
    posting into already answered topic (greatly answered by Barry).

    >
    > > But as my colleagues here said, it is compiler dependent (this code
    > > can be just junk)

    >
    > Which is to say, the previous explanation is not correct, and has no meaning.

    It is not correct, it is compiler dependent, that is the
    difference :).

    I know maybe you will not understand if you have ever tried just one
    compiler or you are thinking that all C compilers are from God and all
    are the same with same parsing, etc.
    My tested compiler was capable of such operations, but I have never
    said it is a standard (Maybe some C999 will mention it).
    Counting I used is a common counting for High Level Languages, these
    are capable to parse such operations, I also tested the code on
    machine and the result supported my idea, but I still never said it is
    a standard.


    So let's summarize it:
    Is it possible for the code to work as I said? Yes, it is possible,
    but it depends on the compiler
    Is it standard for the code to work as I said? No, it is not!
    >
    > -s
    > --
    > Copyright 2009, all wrongs reversed.  Peter Seebach / ://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Processor-Dev1l, Sep 22, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. suzy
    Replies:
    3
    Views:
    450
  2. srikanth
    Replies:
    14
    Views:
    545
    vijay
    Jul 10, 2003
  3. brian

    Size of my Struct? PLZ PLZ reply

    brian, Nov 23, 2004, in forum: C Programming
    Replies:
    7
    Views:
    421
    -berlin.de
    Nov 25, 2004
  4. Replies:
    1
    Views:
    387
  5. asdfghjk
    Replies:
    17
    Views:
    615
    Keith Thompson
    Aug 19, 2010
Loading...

Share This Page