0

Say,the trailing ++ has no actual effect here?

httpinterpret
  • 6,409
  • 9
  • 33
  • 37
  • 8
    It really does not matter what it means. If you use code like that in a real program you should be fired as it makes reading the code hard. Anything that should be simple that you can not read by a glance is definately a code smell and should NOT be used. – Martin York May 16 '10 at 07:23
  • I'm looking for a duplicate, and I'm only finding http://stackoverflow.com/questions/1860461/why-is-i-i-1-unspecified-behavior , where "++i + i" is considered "obviously" undefined. I don't know why it's more obvious than the actual question there, anyway surely some of the answers are good reading. – Pascal Cuoq May 16 '10 at 07:24
  • `l+l++` is the same as `*(int*)NULL`. Both are undefined. :) – jalf May 16 '10 at 10:52
  • possible duplicate of [Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc...)](http://stackoverflow.com/questions/949433/could-anyone-explain-these-undefined-behaviors-i-i-i-i-i-etc) – Bo Persson Aug 23 '12 at 12:42

4 Answers4

16

l+l++ is undefined. There is no sequence point in your expression to separate the access to l and the post-increment. It can do anything, including having the same effects as l+l.

EDIT: the question and answers at Why is `i = ++i + 1` unspecified behavior? explain what a sequence point is, quote the relevant parts of the standard and provide links. Let me quote again:

Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified. 53) Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored.

Emphasis mine.

SECOND EDIT: By popular request, the next sentence in the paragraph:

The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined.

Community
  • 1
  • 1
Pascal Cuoq
  • 79,187
  • 7
  • 161
  • 281
  • @KennyTM As I said in a comment, in another question, "++i + i" is considered as "obviously" undefined, and someone is asking about the assignment instead. What is "obvious" for someone clearly isn't for another, and there always remain the rule that pre/post-incrementing a variable within the same sequence point as another access (be it reading or writing) is undefined. – Pascal Cuoq May 16 '10 at 07:31
  • Of all the answers I ever gave on StackOverflow, I never expected this particular one would be downvoted. It just goes to show... – Pascal Cuoq May 16 '10 at 07:34
  • I don't think it is undefined in the 'can do anything' sense. The order of the operations is undefined, but the operations themselves are well defined (unlike, say, dereferencing null). So it either is the same as `++l, l+l` or `t=l, ++l, l+t` – Pete Kirkham May 16 '10 at 09:18
  • Not quite correct. Unspecified means it must do something and be documented by the compiler. – Martin York May 16 '10 at 09:59
  • Worth noting that `l = ++l` is undefined in C++03, but well defined in C++0x. While `l = l++;` is undefined in both C++03 and C++0x, as is `l + l++` and `l + ++l`. If you compare the respective example paragraph in `5/4` of C++03 and `1.9/15` in C++0x you find that they changed `l = ++l + 1` to `l = l++ + 1` because the former is made valid by C++0x. – Johannes Schaub - litb May 16 '10 at 10:30
  • 1
    @Pete: There is no other sense. Undefined *always* means "can do anything". And in this case, it truly is undefined. There is no requirement that "the compiler must do these operations, but can choose the order freely". (That would make it unspecified) – jalf May 16 '10 at 10:54
  • @Pete it says below that quoted text "otherwise the behavior is undefined." i guess it would be useful to include it into the answer, though :) – Johannes Schaub - litb May 17 '10 at 19:18
  • Suppose I was told to write a function to iterate x times, and that behavior when x was negative was undefined. Things I could do if x is negative: Reformat your hard drive (this is unlikely), loop infinite times, introduce an explicit exception or otherwise deliberately kill the program, introduce an accidental crash, jump to an arbitrary point in your program's execution, or anything else. The case of a crash or arbitrary jump often implies leaving behind a security hole in your application. – Brian May 17 '10 at 20:41
0

This will post-increment l i.e. compute l+l and increment l after that, so it has some effect.. Demo code:

#include <iostream>

int main() {
       int l = 1;
       std::cout << "l+l++ = " << l+l++ << std::endl;
       std::cout << "l = " << l << std::endl;
       return 0;
}

EDIT: Note that this compile with a warning (see Pascal's answer):

main.cpp: In function ‘int main()’:
main.cpp:5: warning: operation on ‘l’ may be undefined
Community
  • 1
  • 1
-1

Be warned - many languages don't dictate the order operands are evaluated, so you may see 2*l or 2*l+1 as the result of that expression. In either case l will be one higher afterwards.

Bobby
  • 199
  • 5
-4

If you have i+i++ it is actually acting like something like i+i; i = i + 1

Dr.Optix
  • 463
  • 4
  • 12
  • @jalf undefined because I forgot to day `int i = 1;` or to init it to something else. I just said the long form of `i+i++`. Also from C++ operator precedence `++` have higher priority than `+`: http://www.cppreference.com/wiki/operator_precedence Also here is a PoC that show `i+i++` is the same as `i+i; i = i + 1` #include int main(int argc, char **argv){ int i = 1; printf("i:\t%d\n", i); printf("i+i++:\t%d\n", i+i++); printf("new i:\t%d\n", i); return 0; } – Dr.Optix May 17 '10 at 13:28
  • 2
    @Dr.OPtix: The fact that your particular compiler results in `i+i++` getting a particular value of i means nothing. It's undefined. Your specific compiler happens to have the result you expect, but using code to show empirically what an undefined operation will do says nothing about what a different compiler will do (nor guarantees that your compiler will do so the next time, or with different compilation options). – Brian May 17 '10 at 20:45