5.4 — Increment/decrement operators, and side effects

Incrementing and decrementing variables

Incrementing (adding 1 to) and decrementing (subtracting 1 from) a variable are so common that they have their own operators.

Operator Symbol Form Operation
Prefix increment (pre-increment) ++ ++x Increment x, then return x
Prefix decrement (pre-decrement) –– ––x Decrement x, then return x
Postfix increment (post-increment) ++ x++ Copy x, then increment x, then return the copy
Postfix decrement (post-decrement) –– x–– Copy x, then decrement x, then return the copy

Note that there are two versions of each operator -- a prefix version (where the operator comes before the operand) and a postfix version (where the operator comes after the operand).

The prefix increment/decrement operators are very straightforward. First, the operand is incremented or decremented, and then expression evaluates to the value of the operand. For example:

This prints:

6 6

The postfix increment/decrement operators are trickier. First, a copy of the operand is made. Then the operand (not the copy) is incremented or decremented. Finally, the copy (not the original) is evaluated. For example:

This prints:

6 5

Let’s examine how this line 6 works in more detail. First, a temporary copy of x is made that starts with the same value as x (5). Then the actual x is incremented from 5 to 6. Then the copy of x (which still has value 5) is returned and assigned to y. Then the temporary copy is discarded.

Consequently, y ends up with the value of 5 (the pre-incremented value), and x ends up with the value 6 (the post-incremented value).

Note that the postfix version takes a lot more steps, and thus may not be as performant as the prefix version.

Here is another example showing the difference between the prefix and postfix versions:

This produces the output:

5 5
6 4
6 4
6 4
7 3

On the 8th line, we do a prefix increment and decrement. On this line, x and y are incremented/decremented before their values are sent to std::cout, so we see their updated values reflected by std::cout.

On the 10th line, we do a postfix increment and decrement. On this line, the copy of x and y (with the pre-incremented and pre-decremented values) are what is sent to std::cout, so we don’t see the increment and decrement reflected here. Those changes don’t show up until the next line, when x and y are evaluated again.

Best practice

Strongly favor the prefix version of the increment and decrement operators, as they are generally more performant, and you’re less likely to run into strange issues with them.

Side effects

A function or expression is said to have a side effect if it does anything that persists beyond the life of the function or expression itself.

Common examples of side effects include changing the value of objects, doing input or output, or updating a graphical user interface (e.g. enabling or disabling a button).

Most of the time, side effects are useful:

The assignment operator in the above example has the side effect of changing the value of x permanently. Even after the statement has finished executing, x will still have the value 5. Similarly with operator++, the value of x is altered even after the statement has finished evaluating. The outputting of x also has the side effect of modifying the state of the console, as you can now see the value of x printed to the console.

However, side effects can also lead to unexpected results:

C++ does not define the order in which function arguments are evaluated. If the left argument is evaluated first, this becomes a call to add(5, 6), which equals 11. If the right argument is evaluated first, this becomes a call to add(6, 6), which equals 12! Note that this is only a problem because one of the arguments to function add() has a side effect.

There are other cases where C++ does not specify the order in which certain things are evaluated (such as operator operands), so different compilers may exhibit different behaviors. Even when C++ does make it clear how things should be evaluated, historically this has been an area where there have been many compiler bugs. These problems can generally all be avoided by ensuring that any variable that has a side-effect applied is used no more than once in a given statement.


C++ does not define the order of evaluation for function arguments or operator operands.

Best practice

Don’t use a variable that has a side effect applied to it more than once in a given statement. If you do, the result may be undefined.

5.5 -- Comma and conditional operators
5.3 -- Modulus and Exponentiation

202 comments to 5.4 — Increment/decrement operators, and side effects

  • Professzore

    Let me ask something.

    Rule: Don’t use a variable that has a side effect applied to it more than once in a given statement.

    It's clear. Let's talk a bit about those two examples of "risky" codes.

    is a "risky", meanwhile using

    instead may be a good solution?

    As well as

    is less trustable as

    Am I right?

  • bert

    I believe you meant to use "versions" in the following:

    There are actually two version of each operator

    Maybe you were trying to tease on the next one and i'm too literal to get it, but you used "any" twice in:

    These problems can generally all be avoided by ensuring that any any variable that has a side-effect applied is used no more than once in a given statement.


  • Damien

    Hi Alex,

    I am confused on this section below, just can't seem to get my head around it. Probably i'm completely misunderstanding it.. but wouldnt the ++ be applied to x before the assignment due to the precedence of ++ being higher than =? Would you please be able to explain what the compiler is doing in each situation, i.e. when ++ is applied to x before or after assignment?

    Hope this makes sense.


    This is the part i'm confused about:

    What value does this program print? The answer is: it’s undefined. If the ++ is applied to x before the assignment, the answer will be 1. If the ++ is applied to x after the assignment, the answer will be 2.

    • Alex

      Operator++ does have higher precedence than operator=, which is why it's evaluated first. So first, x++ evaluates to 1. At this point, one of two things can happen:
      * x gets incremented, then the value of 1 from the evaluation of x++ is assigned to x (result: x=1)
      * the value of 1 from the evaluation of x++ is assigned to x, then x gets incremented (result: x=2)

      You don't really need to understand this to a high degree -- just know that you should never apply more than one side effect to a given variable in a single statement.

      • Nguyen

        Hi Alex,

        I am confused about the same part.

        "If the ++ is applied to x before the assignment, the answer will be 1. If the ++ is applied to x after the assignment, the answer will be 2."

        int main()
            int x = 1;
            x = x++;
            std::cout << x;

            return 0;

        I don't know if the example needs to be modified.  If yes, Could you please write out the new statements for "++ is applied to x before/after the assignment".


        • Alex

          The example doesn't need to be modified (it's a fine example of a statement you should never write).

          All you really need to know is using a variable with side effects applied more than once in a given statement may lead to undefined results, because different compilers may interpret these differently.

  • Ton

    The GNU C++ compiler issues the next warning:
    main.cpp:35:27: warning: operation on ‘x’ may be undefined [-Wsequence-point]
         int value = add(x, ++x); // is this 5 + 6, or 6 + 6?  It depends on what order your compiler evaluates the function arguments in

    So you can't say you're not warned!

  • Nyap

    i don't get the postfix increment/decrement operators. From my understanding;
    x++ == x
    x-- == x
    what's the point?

    • Alex

      x++ returns a copy of x, and then increments x.

      The above snippet should print 56.

      So this is useful when you want to increment x after using it.

  • Confusion in evaluation sequence of increment and decrement operator is one of the major causes of bugs in my programs. Hence, I started using brackets like (var++) and (++var).

  • Alex

    Using a variable with side effects more than once in a given statement results in undefined behavior. The compiler could return 4, 5, or 6.

    What's most likely happening in your case is that i++ returns its value first, and then increments i.

    2 + 2 * i++ = 2 + 2 * 1 = 4. 4 gets assigned to i. Then the ++ takes effect, and increments i, to get 5.

  • Jaspreet

    Int i =1;
    i = 2+2*i++;
    The ans is 5 . Why ??? It should be 6 or 4

    • Jim

      I know this is a very old comment, but I will try and answer in case it helps anyone else reading this (because I was confused by the comment's example also!)

      i = 2+2 * i++;

      So first we evaluate i++ -- since postfix++ returns the value of i before incrementing, that will evaluate to 1.

      Now we evaluate the multiplication, so the statement is: i = 2+(2*1) which then evaluates to i = 2+2 and further to i = 4.

      HOWEVER, now the value of i gets incremented from the original postfix++ operator, so i = 5.

      Hopefully that is correct and makes sense -- if I have any of that wrong, please let me know!

  • Elpidius

    Great job Alex with these tutorials, although I didn't fully understand what a side effect was from reading this sub-chapter. So I decided to do a bit of research to help clarify what a side effect is. I've put in what I've collected below. I know one example below uses the function printf() (which is used in the C language) instead of cout, but as C++ supercedes C, this function also works in C++ and is still relevant. Here's the information I've found below:

    A computer program stores data in variables, which represent storage locations in the computer's memory. The contents of these memory locations, at any given point in the program's execution, is called the program's state.

    Any operation which modifies the state of the computer or which interacts with the outside world is said to have a side effect. See Wikipedia on Side Effect.

    For example, this function has no side effects. Its result depends only on its input arguments, and nothing about the state of the program or its environment changes when it is called:

    In contrast, calling these functions will give you different results depending upon the order in which you call them, because they change something about the state of the computer:

    This function has the side effect of writing data to output. You don't call the function because you want its return value; you call it because you want the effect that it has on the "outside world":

    One common demonstration of side effect behavior is that of the assignment operator in C++. For example, assignment returns the right operand and has the side effect of assigning that value to a variable.

    I just thought I'd mention that an evaluation of expression does not have a side effect if it does not change an observable state of the machine, and produces same values for same input.

    It also should be noted though that side effects can be much more than just modifications of the operands, it can also involve modifications of other objects, global data, I/O operations etc. Basically, anything that makes changes besides the return-value is a side effect.


    • Elpidius

      //Here's another explanation for side effects complementary to the explanations I've mentioned thus far:

      What exactly is a 'side-effect' in C++? Is it a standard term which is well defined?

      c++11 draft - 1.9.12: Accessing an object designated by a volatile glvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression (or a sub-expression) in general includes both value computations (including determining the identity of an object for glvalue evaluation and fetching a value previously assigned to an object for prvalue evaluation) and initiation of side effects. When a call to a library I/O function returns or an access to a volatile object is evaluated the side effect is considered complete, even though some external actions implied by the call (such as the I/O itself) or by the volatile access may not have completed yet.

      What is the significance of a 'side effect'?

      The significance is that, as expressions are being evaluated they can modify the program state and/or perform I/O. Expressions are allowed in myriad places in C++: variable assignments, if/else/while conditions, for loop setup/test/modify steps, function parameters etc.... A couple examples: ++x and strcat(buffer, "append this").

      In a C++ program, the Standard grants the optimiser the right to generate code representing the program operations, but requires that all the operations associated with steps before a sequence point appear before any operations related to steps after the sequence point.

      The reason C++ programmers tend to have to care about sequence points and side effects is that there aren't as many sequence points as you might expect. For example, given

      you may expect a call to f(2, 3) but it's actually undefined behaviour. This behaviour is left undefined so the compiler's optimiser has more freedom to arrange operations with side effects to run in the most efficient order possible - perhaps even in parallel. It also avoid burdening compiler writers with detecting such conditions.

      1. Is the comma operator free from side effects?

      Yes - a comma operator introduces a sequence point: the steps on the left must be complete before those on the right execute. There are a list of sequence points at - you should read this! (If you have to ask about side effects, then be careful in interpreting this answer - the "comma operator" is NOT invoked between function arguments, array initialisation elements etc.. The comma operator is relatively rarely used and somewhat obscure.

      2.Side effects when passing objects to function in C++

      When calling a function, all the parameters must have been completely evaluated - and their side effects triggered - before the function call takes place. BUT, there are no restrictions on the compiler related to evaluating specific parameter expressions before any other. They can be overlapping, in parallel etc.. So, in f(expr1, expr2) - some of the steps in evaluating expr2 might run before anything from expr1, but expr1 might still complete first - it's undefined.

      //One more explanation:

      The term "side-effect" arises from the distinction between imperative languages and pure functional languages. A C++ expression can do three things:

      1. compute a result (or compute "no result" in the case of a void expression),
      2. raise an exception instead of evaluating to a result,
      3. in addition to 1 or 2, otherwise alter the state of the abstract machine on which the program is nominally running.

      (3) are side-effects, the "main effect" being to evaluate the result of the expression. Exceptions are a slightly awkward special case, in that altering the flow of control does change the state of the abstract machine (by changing the current point of execution), but isn't a side-effect. The code to construct, handle and destroy the exception may have its own side-effects, of course.

      The same principles apply to functions, with the return value in place of the result of the expression.


      just computes a return value, it doesn't alter anything else. Therefore it has no side-effects, which sometimes is an interesting property of a function when it comes to reasoning about your program (e.g. to prove that it is correct, or by the compiler when it optimizes).

      The following function:

      does have a side-effect, since modifying the caller's object "a" is an additional effect of the function beyond simply computing a return value. It would not be permitted in a pure functional language.

      Alex, your definition of a side effect is: "a side effect is a result of an operator, expression, statement, or function that persists even after the operator, expression, statement, or function has finished being evaluated."

      The stuff in your quote about "has finished being evaluated" refers to the fact that the result of an expression (or return value of a function) can be a "temporary object", which is destroyed at the end of the full expression in which it occurs. So creating a temporary isn't a "side-effect" by that definition: other changes are.


  • Lokesh

    I guess
    "... one of the parameters to x has a side effect."
    should be
    "... one of the parameters to add() has a side effect."

  • Reaversword

    Please Alex, I'm looking forward to read your answer over my question. I think "Tormentor" did a question just the same day than me and possibly you didn't realize about it. Thanks for, it is an incredible well explained guide.

  • Tormentor

    What does this mean?
    Also, what is it used for?

    It was in my school assignment.

  • Reaversword

    I don't know if comment this here or in functions page.
    Using Visual Studio 2015 under windows7x64.

    First line couts: X:3, Y:2, Z:1. Result of the side effect: 6.
    Second one couts: X:3, Y:3, Z:3. Result of the side effect: 9.

    But what really I didn't expect was X:3 and Z:1. Why it isn't in opposite? (X=1,Y=2,Z=3)?. Isn't that the order of the call (the order sending arguments to the function)
    This issue is about how function takes arguments, or how internally "++" works?

    • Alex

      C++ does not guarantee whether function parameters will be evaluated from left to right or right to left. Furthermore, using an variable with side-effects more than once in a single expression will yield indeterminate results.

  • rtz

    can someone explain me why output of the following is 11 and not 10?

    i was expecting the temporary value 10 to be initialized to 'a' after 'a' has been incremented from 10 to 11.

    • Alex

      Don't do this. You're breaking the rule: Don't use a variable that has a side effect applied to it more than once in a given statement.

      The statement a = a++ results in undefined behavior, and different compilers may product different results (some will say the answer is 10, others 11).

  • Len

    "Rule: Favor pre-increment and pre-decrement over post-increment and post-decrement. The prefix versions are not only more performant, you’re less likely to run into strange issues with them."

    No wonder I keep running into strange issues. From now on I will refer to this language as ++C.

    • Nigel (still learning@50)

      Hi Alex,
      So... if i've understood you correctly. Would the following snippet be considered acceptable programming:-
      #include <iostream>
      using namespace std; // "i'm a lazy typist."
      int add(int x, int y){
      return x+y;
      int main(){
      int x(5); int z(5);
      int value = add(x, ++z);  /* or z++ however
      prefer preincrement/predecrement */
      cout << value;
      return 0;
      which i assume will produce the result of 11 on all compilers. As the point being, we're avoiding, reassigning a value to 'x' in the same statement "add(x, ++x)". : warning unsequenced modification and access to 'x'. As reported on my phone app, CCTools. In which your example in this lesson, refused even to compile, hence your warning,
      I also use codeblocks/laptop  for comparison
      its less fussy. sorry if this text seems verbose.
      Thanks again Alex.

  • Hey Alex! something is wrong. I am unable to write xminusminus (post decrement of a variable 'x'). When I type xminusminus and looking back to my posted comment, I only see a single minus after x (something like 'x-'). That is not a big problem and you can ignore this . I am only trying to clear that you made a mistake in the table above. Sorry for this extra comment.

    It is okay when I use [code] tag.

    Take a look at the last row of the table (the table which is showing the two versions of increment-decrement operators) :

    "Postfix decrement (pre-decrement)" |   --   |  x--  | Evaluate x, then decrement x

    should be:

    "Postfix decrement (post-decrement)" |  --  |  x--  |  Evaluate x, then decrement x

    One question. I m not very good in math. Can I still be a good programmer? How math is related to programming?

    • Alex

      What browser are you using? It looks okay to me on Chrome, Firefox, and IE.

      As for programming and math, it depends on what kind of programming you want to do. If you're going to do complicated stuff with algorithms, 3d graphics, probability, or simulations, then yes, having a good math background is important. If you're going to do business programming, or functionality for web pages, or user interfaces, then you probably won't need much math.

      What's more important is being good at logic.

      • I m using chrome. Thnx.
        Looks like you didn't noticed what I said.   Alex I was talking about the table (post decrement, pre decrement table). You made a typo I think, in the last row of table.

        Postfix-decrement (pre-decrement)

        Should be:

        Postfix-decrement (post-decrement)

        Hope it is clear now.

  • am

    Can anyone explain why the output is 11 9 11?

    • Alex

      Honestly, I'm not sure.

      operator<< evaluates from left to right, so I'd expect the following to happen: a = 10 ++a = 11, which gets printed. a++ means 11 gets printed, a is incremented to 12. --a = 11, which gets printed. So I'd expect 11 11 11. But Visual Studio 2010 and 2013 prints 11 9 11. Visual Studio 2008 prints 10 9 11. So even different compilers don't agree. It's possible that the compilers just aren't handling this case correctly. Which would be more evidence not to use a variable that has a side effect applied to it more than once in a given expression.

  • techsavvy....aye


  • techsavvy....aye

    Hi! Alex.
    The program u have given above is displaying a blank o/p what could be the possible problem?
    please help!

    • Alex

      This program doesn't print anything, so there's no output.

      I updated the sample program to print value, so you can see whether it equals 11 or 12 on your compiler.

  • zhiwei

    Hi ,Alex,  I am confused . because " ++ " is higher precedence than " = "

    so I think first x++ ,and then y = (x++),  so y is 6 .

    please correct me if i am wrong!! Thanks.

    • Alex

      Great question, and yes, you are wrong. :)

      As you correctly note, ++ has higher precedence than =, so x++ evaluates first. What happens when x++ evaluates? The compiler makes a temporary copy of x's value (5). Then the actual variable x is incremented to 6. Then the value of the copy of x (5) is used for evaluation. Therefore, x++ evaluates to 5, now 6, even though the variable x is now set to 6!

      And thus, "int y = x++" becomes "int y = 5", and thus y is assigned the value of 5.

      You can validate that this is true by putting this line in your compiler and then printing the value of x and y afterward.

  • Ramadharkumar

    hey, this code give the output 14.
    int t=1;
    t=++t + ++t + t++ + t++;
    that is
    t=2+3 and in postincrement operator 3+4;
    t=2+3 + 3+4;
    t=3+3 + 4+4;
    t=6 +8;
    if the number of preincrement is greater than post then value of post operator is bigest value of preincrement operator;
    for example:
    t=++t + ++t + ++t + t++ + t++;
    output is 20; BECAUSE
    t=2+3+4 + 4+4;
    t=4+4+4 + 4+4;

    • ahleyn

      it's really come t=3+3+4+4?

      • Paperweight

        int t = 1;
        cout << ++t + ++t + t++ + t++;
        outputs 12 (as in 3 + 3 + 3 + 3), but
        t = ++t + ++t + t++ + t++;
        cout << t;

        outputs 14, I think what happens is:
        1. t is declared to be 1.
        1. t is preincremented. t is now 2.
        2. t is preincremented. t is now 3.
        3. t = t + t + t + t is evaluated. from 3 + 3 + 3 + 3, t is now 12.
        4. t is postincremented. t is now 13.
        5. t is postincremented. t is now 14.
        6. t is printed.

        • Paperweight

          Actually I'm probably wrong.

          //But wait! There's more!

          int t = 1;
          cout << t++ + t++ + t++ + t++ << endl;
          cout << t << endl << endl;
          // Should evaluate 1 + 1 + 1 + 1 as 4,
          // then output 4,
          // then increment t four times to 5,
          // then output t as 5.
          // Actually outputs 4 and 5 OK.

          t = 1;
          t = t++ + t++ + t++ + t++;
          cout << t << endl << endl;
          // Should evaluate 1 + 1 + 1 + 1 as 4,
          // then set t to 4,
          // then increment t four times to 8,
          // then output t as 8.
          // Actually outputs 8 OK.

          t = 1;
          cout << ++t + ++t + ++t + ++t << endl;
          cout << t << endl << endl;
          // Should increment t four times to 5,
          // then evaluate 5 + 5 + 5 + 5 as 20,
          // then output 20,
          // then output t as 5.
          // Actually outputs 15 and 5 WTF?

          t = 1;
          t = ++t + ++t + ++t + ++t;
          cout << t << endl;
          // Should increment t four times to 5,
          // then evaluate 5 + 5 + 5 + 5 as 20,
          // then set t to 20,
          // then output t as 20.
          // Actually outputs 15 WTF?

          • Alex

            Seems like your compiler may not be doing something quite correctly.

            Should evaluate as 20 and 5, and it does in Visual Studio 2008.

            That's one of the many problems with including multiple expressions with side effects in a single statement. Even if the C++ language guarantees that it will evaluate a certain way (and it may not), your compiler may not do it correctly.


    int t;
    t= ++t + ++t + t++ + t++;
    //result=14 how??

  • nagaraj

    Hi all
    int i=2;
    i=++i * i++ * i++; answer i am geeting is 29
    n=++i*i++*i++; answer i am getting is 27
    printf(“%d”,++i*i++*i++); answer i am getting is 36
    for same expression getting different values..please sort this problem

    how complier is going evalute? please reply me…

    • printf for some reason seems to evaluate the i++ once it's done, so it's 3 (you incremented it before using it - ++i) * 3 * 4.
      the second case (n=) simply evaluates the i++, and since the other additions are done only after the statement is done, you get 3*3*3
      the first case is the same as the second one, except it adds +2 gained from the increments (i++) before.

  • nagaraj

    Hi all
    int i=2;
    i=++i * i++ * i++; answer i am geeting is 29
    n=++i+i++*i++; answer i am getting is 27
    printf("%d",++i+i++*i++); answer i am getting is 36

    how complier is going evalute? please reply me...

  • smitha

    Hi, I teach C++ to 12th graders. I encountered this problem in the lab wherein the statement

    I would expect the value 13, but my students got 14 as the output. any pointers?
    what is funny is that the following code gives the value 13.

    The only difference being in the way x is initialized. I am baffled!!!

    • pravin

      answer to the second code snippet is also = 14

    • X000X

      Remember that operator precedence requires that ++ be evaluated before + and =. So what happens is ++y is evaluated twice with y becoming 6 then 7. The addition 7+7 is then performed before finally assigning result 14 to x.

    • Kush

      I fear I also got two different answers, using Turbo c IDE.

      Now, the answer might lie in Order of precedence, though i cannot satisfactorily expalin it.

      Here, acc to table Alex gave:

      Pre-increment and Dynamic initialization fell in third box, with evalauation going Right to left.
      Therefore in second scenario, the case might be:
      (Going Left to Right)

      int x ( This evaluates third, giving x=13) = ++y(This evalautes second, giving y=7) + ++y (This evaluates first, giving y=6);

      IN first case, no dyanmic initialization, and hence, x is evaluated pretty much same way.
      x = ++y + ++y;
      Both ++y having higher precedence, than any other operand in statement are evaluated to 7 apeice, giving answer 14.

      Though, I think this can explain it, I would like to have confirmation.... I will post it out on forums sometime... and see if anyone agrees with me, or provides better explanation.

    • technocrat

      Hello buddy, dont panic, your students r right ,try to understand this-
      int y=5,x;
      x=(++y)+(++y);// x=6+7=13 but when compiler encounter 1st expresion ++y it increment value of y to 6 now y is 6 nd when it encounter another ++y in statement ++y, value of y becomes 7 now notice that compiler now have or assign value of y to 7, now compiler treats all occurence of y value to 7 in statement before assining value to x,so whether it is
      x=6+7;//incremented or say highest value of y becomes value of y for compiler before assigning to x nd therefore expression becomes
      or consider another ex. for better understanding
      x=6+7+8;//incremented or highest value of y will become value of y before assining to x so it becomes-
      x=32; hope that u can understand now,thanks.

    • It's as technorat said.
      consider this expression: x = (a++) + (a++);
      now what happens is it takes the value of a, adds the value of a to it, and then does the incrementing (if a = 5, then x will be 10, and a will be 7 in the end).
      It's the same thing when having ++ in front.
      example x = (++a) + (++a);
      It takes a value, increments it, then it sees another ++ in the statement, so it increments 'a' again, and then it does the adding, meaning that if a was 5, then x will be 14, and a will be 7 in the end.
      Also - you don't really need the brackets in this case, as ++ has higher priority than the standard + sign (tho it helps the readability).

  • oh no . complecated. need to learn easiest way.

  • moncef

    hi Alex!

    I tried to test the precedence of the ++ operator, both prefix and postfix.
    The code i typed in is:

    Why the is ++x++ illicit?
    Thanks for the nice tutorial.

    • Alex

      ++x++ evaluates as ++(x++) due to post-increment having a higher precedence than pre-increment.

      Note that both versions of ++ need to operate on an lvalue (a variable that has an address). With pre-increment, because the increment is done before the value is evaluated, the value is returned as an lvalue. However, with post-increment, the value gets evaluated before the increment, so the value is returned as an rvalue.

      So in your expression, x++ is returning an rvalue, and pre-increment can't work with an rvalue, so the compiler throws an error.

      Note that if you write the expression as (++x)++, then it does work, because (++x) returns an lvalue that can be operated on by post-increment.

  • Danny

    It says above that... "C++ does not define the order in which function parameters are evaluated."
    But in the section "Precedence and associativity" it shows that () "Parenthesis", () "Function calls", () "Implicit assignments", and , "comma" have an associative of left to right... what is the difference?

    • Dogbiscuit

      No, what he said is that function parameters could be done left to right, or right to left. E.g.

      It's not defined whether you do a + b or b + a (makes no difference in this case, but with increment/decrement operators it could get messy.

    • Alex

      I can see how this would be confusing. The comma used inside a function call parameter list to separate the parameters isn't the comma operator. So while the comma operator does have a left to right association, the order that parameters inside a function call are processed could be either direction.



    SUM = SUM + (++CTR)

    THE VALUE IS 15 .....HOW?

    SUM = SUM + (--CTR)

    THE VALUE IS 15 .....HOW?

    SUM = SUM + (CTR++)
    THE VALUE IS 16 .....HOW?

    SUM = SUM + (CTR--)
    THE VALUE IS 16 .....HOW?

    thanx in advance

    • Peter P

      Tried to evaluate the first expression and I get the expected result SUM = 17.

      Have not tried the other exampels but assume I will get the expected results as well. No idea how you end up with your results?!

    • csvan

      At face value this looks strange...I will go over them in order.

      1. This one should evaluate to 17, like Peter P said. There is no way it can evaluate to 15, since it will become: (SUM = 12 + 5).

      2. again, something is wrong. This one should be (I think), SUM = 12 + (-4) = 8.

      3. This one should be correct, as the postfix ++ will increment CTR AFTER the expression is evaluated (I think).

      4. I have never seen a single - postfixed like this, I dont believe it should even compile.

      Use your compiler to try and compile each statement, and see what happens. I have just written my observations here, I did not compile the code.

  • som shekhar

    you have written the statement for the post fix increment as;

    The postfix increment/decrement operators are a little more tricky.
    The compiler makes a temporary copy of x, increments x,
    and then evaluates the temporary copy of x.

    but compiler should first evaluate the temporary copy of x and then it should increment x.
    please correct me if i am wrong!!

    Som Shekhar

    • I believe what I wrote is correct. If you find something that seems to indicate otherwise, let me know.

      • I don't know the internals of the C++ compilers, but I can see how this is confusing. May I suggest that unless you know the compiler actually does it in that order that you change it to:

        The compiler makes a temporary copy of x, evaluates the temporary copy of x, and then increments x.

        As this will make it clearer that that the increment of x does not affect the copy of x. If I'm not mistaken mr Shekhar understood the copy as a pointer like thing, whereas I assume you meant a complete clone of the memory for x.

        Another suggestion, what about motivating people to use the debugger for code like this? This seems like the perfect place to get some simple and safe experience, where the debugger may make it more clear what actually happens. I guess the challenge here is what debuggers people will use though :/ but yeah just a thought :)

        • Antoine Danibo

          You should remember it's a tutorial for beginners. If you tell them about the internal functionning of the compiler when they just learn something new, they won't focus on anythig and will get lost.

          • Alex

            I'm okay with discussion of related more advanced topics in the comments section. Users who are curious can gain additional knowledge. Users who do not have the foundational knowledge to understand the comments can simply skip them without worrying about whether that will impact their understanding of future tutorial material.

        • Alex

          The most reliable reference materials I've found indicates that the increment of the original object happens before the evaluation of the copy.

    • Darren

      is equivalent to,

      Whereas writing

      is equivalent to,

Leave a Comment

Put all code inside code tags: [code]your code here[/code]