Talk:Sequence point

From Wikipedia, the free encyclopedia
Jump to: navigation, search


Regarding this change: I realise that when operators are overloaded there are necessarily additional sequence points due to the extra function calls, but this applies to many of the other cases as well - in certain ways, C++ overloaded operators are a whole different ball game.

By definition when operators are overloaded, the ++ has to store its result first and make a copy of the old value, but for built-in types is the compiler not free to use any valid instruction order between sequence points as had been described? I admit I expanded on that section slightly when merging without consulting other sources though.

Of course, half of the point is that for any sensible expression, it doesn't matter what order these different values are updated... but it could make a difference if (for example) p happens to point to the location where its own value (or that of q) is stored, etc.


I'm relativly sure the following paragraph is incorrect.

Consider two functions f() and g(). In C and C++, the + operator is not a sequence point, and therefore in the expression f()+g() it is possible that either f() or g() will be executed first. The comma operator is a sequence point, and therefore in the code f(),g() the order of evaluation is defined (i.e., first f() is called, and then g() is called). The type and value of the whole expression are those of g(); the value of f() is discarded.

According to C99 Program execution Example, The function f() is guaranteed to be called before g(). Also on page 74, it also mentions that left associative operators of equal precedence will be executed in left to right order. The function f() will defiantly be called before g(). —Preceding unsigned comment added by (talk) 04:14, 17 February 2009 (UTC)

That is incorrect. Nowhere in C and/or C++ language specifications it says that built-in left-associative operators are executed in left-to-right order. There's no such example in and there's nothing even remotely relevant on page 74 of C99. Please, clarify where you are getting this from.
Why do we care where he gets it from? As you say, it's incorrect. — DAGwyn — Preceding unsigned comment added by (talk) 21:42, 20 June 2011 (UTC)
You're mixing up expression evaluation with operator precedence. The latter only describes how the value of a statement is constructed using fixed, i.e. already evaluated values. Expression evaluation, however, is the process of getting a value from an expression. I.e. "a+b+c" is an expression and each variable is evaluated, i.e. its value is read from memory. In "a+g()+c", a and c are read and g() is called in order to evaluate the expression of g(), i.e. to get its (return) value. In "f()+g()+h()", each function is called and let's assume that the results are 1, 2 and 3. Afterwards the value of the expression is formed by adding "1+2+3" and that is done - as you said - by doing left-associative adding, i.e. first adding 1+2 and then the result is added with 3, i.e. (1+2)+3. The order of the function calls f(), g() and h() , however, is total unspecified. (talk) —Preceding undated comment added 09:47, 4 December 2013 (UTC)

How undefined is indeterminately sequenced?[edit]

The article contradicts itself when it states that C++11's possibilities of sequencing include "indeterminately sequenced (one of the above but which is not defined)." The "one or the other" sounds like unspecified behavior, but the "not defined" sounds like undefined behavior. The difference is important because one "can result in time travel" according to Raymond Chen and the other can't. So which is it? --Damian Yerrick (talk) 15:03, 12 July 2015 (UTC)

Found it: says it's unspecified, and it implies that the difference between indeterminately sequenced and unsequenced parallels the difference between unspecified and undefined. --Damian Yerrick (talk) 01:05, 15 October 2015 (UTC)