Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 35 replies
  • Answers 3 answers
  • Subscribers 51 subscribers
  • Views 15505 views
  • Users 0 members are here
Related

multiple pre increment/post increment in expression of C language

dr.akshay_1980@yahoo.com

I would like to know the explanation for the following expression evaluation in C under windows TURBO c..

void main()

{

     int i=4;

    int x;

    x= ++i + ++i + ++i;   // i becomes 5 then 6 added becomes 11 and then incremented to 12 so 11+12=23   

    printf("%d",x);

    getch();

}

when the above was executed value of x comes out to be 21

 

Slightly eliminating the x variable in the above

 

void main()

{

    int i=4;

    printf("%d", ++i + ++i + ++i);   //accordingly at this step  5+6+7=18

    getch();

}

when the above is executed the answer comes out to be 18


Can anyone provide a decent explanation step by step and why two answers are different???


Thanks in advance.

Akshay


Parents
  • 0

    If you did about inside C which I have done a few times.. the standard K&R says I= I++ + I++ ok but not realy. here's what is allowed i = i++ + b++ is valid on its face and is repeatable. as i is on the left side of the = this is where the value of i++ + b++ if I and b both  = 5 before now here is the funny chuck of it:

    we all know 5 + 5 = 10 right so after the assignment i becomes 10 right?

    then I and b are both incremented. which become 6 + 6 but whatever happened to the poor i on the left side of the = is it 10 or 11 which state takes precedence over the other? you see the BNF will only get you so far you also need the "state table" and thats where that info is. Nobody talks about the State Table.

    Question? if this  (i=i++ + i++) posable why couldn't you do this ( i =+i  + i++)    ??????????/

  • 0 in reply to phoenixcomm

    One more nail for the coffin. The big problem is if you look at the BNF ::= i++ = i++ + i++

    it doesn't really mean that you use the variable i in all three spots i just means variable. the problem with assignments where the same variable is on both sides is problematic.   take a look at this: i = i + 1 this could be rewritten as i =+i which tells the compiler to (right hand first) increment  i and then store it in i,  this itself could just be i++ or could it nope, but you could do this i++ = i but you that is the compilers state table will become confused. as most of the time using the same variable on both sides of an assignment statement like a = a; what up with that? the problem is that there is something called an lvalue. Basically, any named object that persists beyond a single expression is an lvalue. So by using the same lvalue on both sides of the assignment statement, you can get some bizarre results.  The problem lies in the finite state machine. that takes your input tokenizes it and determines what to do next. To show you I will use a simple c statement.  return ( a+b ); seems innocuous at first. heres what goes on. 

    1 reads: return finds that it is a keyword. checks bnf to find out whats next

    2. ' ' white space; this is ignored by C

    3. ( Optional (statement to follow)

    4. ' ' white space; this is ignored by C

    5.  a followed by + means this is a statement. get the value for a from the Data Dictionary.

    6. +  this is a standard C operator "ADD" BNF::= <i>[+]<i>

    7  b  this is a variable (and was expected) get the value from the Data Dictionary.

    8. ' ' white space; this is ignored by C

    9. ) Close paren.

    10. ; end of line.

    The compiler on the second or third pass puts the value of the addition of the two lvalues a, b on the stack and returns you will note that the return is not a lvalue. as it is transitory,  or temporary.

Reply
  • 0 in reply to phoenixcomm

    One more nail for the coffin. The big problem is if you look at the BNF ::= i++ = i++ + i++

    it doesn't really mean that you use the variable i in all three spots i just means variable. the problem with assignments where the same variable is on both sides is problematic.   take a look at this: i = i + 1 this could be rewritten as i =+i which tells the compiler to (right hand first) increment  i and then store it in i,  this itself could just be i++ or could it nope, but you could do this i++ = i but you that is the compilers state table will become confused. as most of the time using the same variable on both sides of an assignment statement like a = a; what up with that? the problem is that there is something called an lvalue. Basically, any named object that persists beyond a single expression is an lvalue. So by using the same lvalue on both sides of the assignment statement, you can get some bizarre results.  The problem lies in the finite state machine. that takes your input tokenizes it and determines what to do next. To show you I will use a simple c statement.  return ( a+b ); seems innocuous at first. heres what goes on. 

    1 reads: return finds that it is a keyword. checks bnf to find out whats next

    2. ' ' white space; this is ignored by C

    3. ( Optional (statement to follow)

    4. ' ' white space; this is ignored by C

    5.  a followed by + means this is a statement. get the value for a from the Data Dictionary.

    6. +  this is a standard C operator "ADD" BNF::= <i>[+]<i>

    7  b  this is a variable (and was expected) get the value from the Data Dictionary.

    8. ' ' white space; this is ignored by C

    9. ) Close paren.

    10. ; end of line.

    The compiler on the second or third pass puts the value of the addition of the two lvalues a, b on the stack and returns you will note that the return is not a lvalue. as it is transitory,  or temporary.

Children
No Data