Increment differences in C++ and C#

11 Comments

• > What is the value of ‘i’ after this code
  
  > has run?
  
  
  
  'i' doesn't have to have any value. The code doesn't have to finish running. The code is allowed to format your hard disk.
  
  
  
  > it’s dangerous to write expressions that
  
  > include operands with side effects.
  
  
  
  That's an overreaction. Without side effects you wouldn't get anything done. Consider two examples of correct code, maybe this:
  
  
  
  i = i;
  
  i++;
  
  
  
  or this:
  
  
  
  int j = i;
  
  i++;
  
  i = j;
  
  
  
  In the first example, there are two expressions with side effects. The first one doesn't accomplish much but the second one does, and you wouldn't get i incremented without it.
  
  
  
  In the second example, officially there are two expressions with side effects, but the initializer is obviously a moral equivalent to a side effect. The third side effect undoes the result of the first side effect so the net result is null, but still the meaning of each side effect by itself is pretty clear. You wouldn't get much programming done without these kinds of expressions.
  
  
  
  Of course the original code isn't required to be equivalent to either of these two examples. These are two ways in which humans are most likely to think but the standard simply prohibits the original code. The standard doesn't require an implementation to do either of them, nor to do anything else in particular, nor to refrain from anything else in particular.
  

• Dean: thanks for the link. For those of you who want to walk the line between well defined and undefined behavior that may help to avoid falling off unexpectedly. :)
  
  
  
  Norman: I never know when you’re serious and when you’re joking. Regarding the comment about side effects in expressions you should probably read it as I intended it. More clearly: it’s dangerous to write expressions with more than trivial side effects. Naturally there’s nothing wrong with side effects and increment operators are invaluable but you can easily write expressions that are misleading even if they do not produce undefined behavior. As I’ve said before, you really need to get your own blog. :)
  
  
  
  Thanks for the comments!
  
  

• In C# (and Java) it's explicitly defined what a statement like "i = i++" should do, and that's what you see in the C# code.
  
  
  
  The C and C++ standards were largely written by compiler implementors, who like their compilers to look good in benchmarks, so the C/C++ standards goes out of it's way to make certain things "ambiguous" to allow for the compiler to optimize. But C# and Java were designed with different goals, namely to ensure that the same code will run exactly the same way on many different architectures and implementations. That means you really *do* need to be explicit with such constructs.
  
  
  
  And that thing about formatting the hard disk is probably over reacting as well :-) From the standard's point of view, it doesn't care what the result is, but practically speaking it's only ever going to be "1" or "2".
  

• > Norman: I never know when you're serious
  
  > and when you're joking.
  
  
  
  Aha, so now I know who my wife has been taking lessons from.
  
  
  
  Anyway, there is no joke about the fact that the C and C++ standards defined side effects the way they did, the fact that undefined behaviour means undefined behaviour, and the fact that the first two facts here are completely independent but the original code invoked both of them to do its damage.
  
  
  
  > And that thing about formatting the hard
  
  > disk is probably over reacting as well :-)
  
  
  
  Yeah, who ever found their partition formatted and ready to use when they were expecting it not to be? Far more common is the opposite. Who knows how many partitions have had their formatting destroyed by bugs like this vs. how many have been destroyed by bugs different from this. The difference between the way Windows 95 and Windows 98 laid out partitions does look like Windows 98 fixed a bug very much like this one.
  

• Kenny, I'm glad I'm not alone in feeling a shiver down my spine when I see code like this.
  
  As far as I'm concerned, it is far more important to write easy to understand code than it is to exploit every clever shortcut/trick a programming language provides.
  
  But then in my case it could be a case of "simple is as simple does" (to paraphrase Forrest Gump) ;-)
  
  

• The C++ behavior (though undefined in the standard and thus compiler dependent) is the more intuitive one in my opinion.
  
  
  
  The C# behavior is counter-intuitive!
  

• A prefix operator should return the value of the variable AFTER the operation, while a postfix operator should return the value of the variable BEFORE the operation. This should have been the case in C++ from my understanding of the language.
  
  
  
  int i = 1;
  
  i = i++; // should end up with i = 1 since using postfix
  
  
  
  int i = 1;
  
  i = ++i; // should end up with i = 2 since using prefix
  
  
  
  I must have had this same discussion 20 times over the past few months after having discovered the exact same code while reviewing another developer's bug. Regardless of the outcome, code like this can be confusing and should be avoided.
  

• I agree with Ron in what he said. However, when assigning i = i++, that will yield 2, because i++ modifies i. if you did, say,
  
  
  
  int i = 1;
  
  int j = i++;
  
  
  
  then j would be 1, because it's a post increment, but now i is 2.
  
  
  
  int i = 1;
  
  i = i++;
  
  
  
  and
  
  
  
  int i = 1;
  
  int i = ++i;
  
  
  
  should both result in 2. that's what i read it as when i read it, but i also seem to always miss the easy questions. :)
  
  
  
  -darren
  

• Darren,
  
  
  
  In release mode, the VC++ 2005 compiler optimizes away the assignment.
  

• Actually, I think I can see what the difference could be.
  
  I think it all depends on what you actually think i++ returns. If i++ returns "the variable i, which will be incremented by 1 afterward", then it should be 2, as with c++. Logically, i is set to itself, and then i is incremented.
  
  However, if you define i++ to return 'the value of i, before it is incremented (now)', then i++ will evaluate to 1, and as part of that evaluation, i will be incremented to 2. Then, the result of that evaluation (1) will be assigned to i, and i becomes 1 again.
  
  Personally, because incrementing is a value-type operation, I prefer the latter- I want i to be incremented as a part of the expression i++, before the greater expression i = i++ is evaluated.
  
  Sadly, I came upon this page when googling for "comma operator in c#". Woe is me.
  

• It doesn't matter what it produces. What most people fail to realize about undefined behavior is that the compiler can glean additional information from it.
  
  In the case of i = i++, the compiler (for example) can assume that i and i cannot alias each other so that all writes to i don't affect reads from i. Then it can go off and use that information to reorder code in strange ways (including subtle ones that manifests itself on rare conditions), like loops that never terminate because it hoisted the read from i inside a loop to above the loop.