9

I read about 'side effect' from this website:

but still not understand why f = f++ considered unsafe ?

Can somebody explain?

Ólafur Waage
  • 68,817
  • 22
  • 142
  • 198
  • Duplicate (though not really obvious if you don't know the answer why) http://stackoverflow.com/questions/1678519/difference-between-i-and-i – Martin Beckett Nov 07 '09 at 01:50
  • 1
    There is also a question somewhere about why "++i++" is illegal but it's impossible to search for it ! – Martin Beckett Nov 07 '09 at 01:53
  • 3
    This question explicitly asks why this construct is unsafe. The question that you reference has code that is invalid _because_ this construct is unsafe. Two different completely valid questions. – joshperry Nov 07 '09 at 02:06
  • yes, that's why I didn't vote to close - but it's worth reading the other thread as well. – Martin Beckett Nov 07 '09 at 02:35

5 Answers5

16

The problem is Sequence Points. There are two operations in this statment with no sequence point, so there is no defined order to the statement, is the assignment happening first or the increment?

Nothing says it's unsafe, it's just undefined, which means that different implementations may have different results or it may format your hard drive...

joshperry
  • 41,167
  • 16
  • 88
  • 103
  • 2
    I think most people would consider formatting a drive an unsafe consequence of `f = f++`. Though I think most people say 'unsafe' not meaning that it may destroy something, but that you can't depend on what it'll do. – Michael Burr Nov 07 '09 at 02:30
  • The C and C++ standard quite explicitly use the term "Undefined Behavior" throughout, and specifically in the section that details sequence point execution order. I was merely using hyperbole to accentuate the difference between unsafe and undefined. – joshperry Nov 07 '09 at 02:57
  • In fact it doesn't, it merely specifies undefined. Think about the difference between NULL and 0 (not in C++ obviously). Zero is a value, NULL is the lack of a value. Undefined means _anything_ could result; yes, including unsafe things, but not necessarily. – joshperry Dec 05 '09 at 19:11
4

Using x and x++ (or ++x) within the same statement is undefined behaviour in C. The compiler is free to do whatever it wants: either increment x before doing the assignment, or after that. Taking Ólafur's code, it might yield f == 5 or f == 6, depending on your compiler.

Arthur Reutenauer
  • 2,622
  • 1
  • 17
  • 15
4

The article at the (cleaned up) link you provided gives the answer. "C makes almost no promise that side effects will occur in a predictable order within a single expression." This means that you don't know in what order the = and the ++ will occur. It's compiler dependent.

If you follow the link from that article to the article about sequence points on the same site, you'll see that the compiler can optimize what and when it writes values back from the registers into the variables.

shoover
  • 3,071
  • 1
  • 29
  • 40
  • One additional bit of clarification - it's not just compiler dependent. What the compiler can do might make no sense at all - even to the point that 2 instances of the same statement (with the same starting value for `f`) could produce entirely different results. – Michael Burr Nov 07 '09 at 02:59
1

From the standard

6.5 (2) If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.74)

74) This paragraph renders undefined statement expressions such as

             i = ++i + 1;
             a[i++] = i;

while allowing

             i = i + 1;
             a[i] = i;
John Bode
  • 119,563
  • 19
  • 122
  • 198
0

I support Arthur's answer in this respect. Though the implementation of the post incrementing operator i.e f++ is confusing, it is not considered unsafe. U should first understand how the compiler interprets it. whether it will increment f after it encounters a sentence termination (;) or immediately after using the value of f.

Aditya
  • 1
  • 1
    It is *undefined*, in the sense of the C standard. This one is not a case of "you have to know what the compiler does". The compiler may do anything, including giving a value to f that does not correspond to any of the orderings of the atomic instructions you think it has to generate. – Pascal Cuoq Nov 07 '09 at 11:45