This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Undefined Behavior and Sequence Points
Pleae explain the behaviour of following statements
int b=3;
cout<<b++*++b<<endl;
How will it be calculated?
The behavior here is undefined. See this question
Relevant standard quote:
§5/4.1 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.
The most common sequence point is the end of a statement.
Also worth noting from the standard:
§5.2.2/8 The order of evaluation of arguments is unspecified.
The standard says this is undefined. The compiler is free to evaluate the statements in any order is sees fit as long as it follows the operator precedence rules. This results in UB:
b++ * ++b; // b is modified more than once
The behavior will be undefined as told by others.
The output depends upon the implementation of compiler.
But as per the standard it should be undefined.
AS this is undefined behaviour, one can't tell the end result. The result depends on the implementation.
Undefined behavior, Compiler is free to evaluate this expression in any order because of the same precedence of the operators. Consider using
(b++)*(++b)
instead
Related
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 3 years ago.
Just to see how much I understood how the ++c/c++ operator works, I tried to run these C programs:
int c = 5;
c = c - c++;
printf("%d\n", c);
prints 1, I guess the logic is that the ++ is applied after the line of code where it's used, so c becomes = c - c which is 0, and on the "next line" it's increased by one. But it seems strange to me, I'd like to know more in detail what should happen with regards to the operators priority.
Now on to this:
int c = 5;
c = c - ++c;
printf("%d\n", c);
this one prints 0, and I can't really understand why. If right hand values are parsed from left to right, I guess it would read c which is 5, then ++c which is 6 as it should be applied immediately. Or does it calculate the ++c before the whole right hand value calculation, so that it's actually doing 6 - 6 because the increment also involves the first calling of c?
For C++ (all versions, explanation applies to C++11 and later):
Both have undefined behavior, meaning that not only is the value that it will return unspecified, but that it causes your whole program to behave in an undefined manner.
The reason for this is that evaluation order inside an expression is only specified for certain cases. The order in which expressions are evaluated does not follow the order in the source code and is not related to operator precedence or associativity. In most cases the compiler can freely choose in which order it will evaluate expressions, following some general rules (e.g. the evaluation of an operator is sequenced after the value computation of its operands, etc.) and some specific ones (e.g. &&'s and ||'s left-hand operands are always sequenced before their right-hand operands).
In particular the order in which the operands of - are evaluated is unspecified. It is said that the two operands are unsequenced relative to one another.
This in itself means that we won't know whether c on the left-hand side of c - [...] will evaluate to the value of c before or after the increment.
There is however an even stricter rule forbidding the use of a value computation from a scalar object (here c) in a manner unsequenced relative to a side effect on the same scalar object. In your case both ++c and c++ cause side effects on c, but they are unsequenced with the use of the value on the left hand side of c - [...]. Not following this rule causes undefined behavior.
Therefore your compiler is allowed to output whatever it wants and you should avoid writing code like that.
For a detailed list of all the evaluation order rules of C++, see cppreference.com. Note that they changed somewhat with the different C++ versions, making more and more previously undefined or unspecified behavior defined. None of these changes apply to your particular case though.
c = c - c++;
In C, this is a very bad idea(a). You are not permitted to modify and modify/use the same object without an intervening sequence point, and that subtraction operator is not a sequence point.
The things that are sequence points can be found in Annex C of the ISO standard.
(a) Technically, the behaviour of each operation (the evaluation of c1 and c++, and the assignment to c) is well defined but the sequencing is either unsequenced or indeterminate. In the former case, actions from each part can interleave while, in the latter, they do not interleave but you don't know in which order the two parts will be done.
However, the standard C11 6.5/2 also makes it clear that a sequencing issue using the same variable is undefined behaviour:
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.
Bottom line, it's not something you should be doing.
This question already has answers here:
Multiple preincrement operations on a variable in C++(C ?)
(2 answers)
Closed 6 years ago.
I have some code with lines which increment a counter.
++ count;
Sometimes I have an if condition which means I should increment count by 2.
count += 2;
Does "double increment'ing" work in the same way?
++ ++ count;
It would be helpful to know if both C and C++ compilers interpret this the same way.
As this is clearly syntactically correct, the question that remains is: "Is this UB because of unsequenced writes?"
It is not (in C++11 and later) because
5) The side effect of the built-in pre-increment and pre-decrement operators is sequenced before its value computation (implicit rule due to definition as compound assignment)
(From here)
So the code is fine as of C++11.
However, the sequencing rules were different before that, and pre-C++11, the code actually has UB.
In C, that code does not even compile.
The fact that the behavior is different between C and C++ and even between different C++ standards and that this question arises in the first place is a hint that the simple count += 2; is the safer and more readable version. You should prefer it over the "cute and clever" ++ ++count;.
There are two methods. One that obviously works, one where you have to ask a question on StackOverflow. There are comments saying "in C++ 11 or later"... How sure are you that your C++ code runs with C++ 11 and not something older? Even if you use extensions that were not part of an earlier language, your language could be C++0x with some extensions.
Clearly you shouldn't care whether the second method works or not, but use the one that obviously works.
In another answer it was stated that prior to C++11, where i is an int, then use of the expression:
*&++i
caused undefined behaviour. Is this true?
On the other answer there was a little discussion in comments but it seems unconvincing.
It makes little sense to ask whether *&++i in itself has UB. The deferencing doesn't necessarily access the stored value (prior or new) of i, as you can see by using this as an initializer expression for a reference. Only if an rvalue conversion is involved (usage in such context) is there any question to discuss at all. And then, since we can use the value of ++i, we can use the value of *&++i with exactly the same caveats as for ++i.
The original question concerned essentially i = ++i, which is the same as i = *&++i. That was undefined behavior in C++03, due to i being modified twice between sequence points, and is well-defined in C++11, due to the side-effects of the assignment operator being sequenced after the value computations of the left and right hand sides.
It is perhaps relevant to note that the non-normative examples in the C++98 and C++03 standards, were incorrect, describing some cases of formally Undefined Behavior as merely unspecified behavior. Thus, the intent has not been entirely clear, all the way back. A good rule of thumb is to simply not rely on such obscure corner cases of the language, to avoid them: one should not need to be a language lawyer in order to make sense of the code…
I think the question only makes sense if we deal with the expression:
i = *&++i;
The relevant quote in the C++03 standard would be [expr]/4:
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. 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.
The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined.
i = ++i + 1; // the behavior is unspecified
We can just compare the sequencing of i = *&++i vs i = ++i + 1 to determine that the same rule causes both to be unspecified. They are both statements of the form:
i = f(++i);
For any function f, the reading of i on the left-hand side and the side-effect of the ++i on the right-hand side are not sequenced relative with each other. Hence, undefined behavior.
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 8 years ago.
Firstly, this is an attempt to understand how operator precedence works and not being used by me in any of my projects.
int *a=new int[3];
a[0]=3;a[1]=7;a[2]=11;
*a*=++*a**a++;
cout<<*(a-1)<<endl<<*a<<endl<<*(a+1);
Gives the following output,
4
112
11
I am expecting the following output,
64
7
11
Can someone please tell me how this is happening?
Thank you
Even by respecting operator precedences, you're not respecting sequence points and thus invoking undefined behavior.
Take a look at the cpp faq here: http://www.parashift.com/c++-faq/sequence-points.html
The C++ standard says (1.9p7),
At certain specified points in the execution sequence called sequence
points, all side effects of previous evaluations shall be complete and
no side effects of subsequent evaluations shall have taken place.
For example, if an expression contains the subexpression y++, then the
variable y will be incremented by the next sequence point. Furthermore
if the expression just after the sequence point contains the
subexpression ++z, then z will not have yet been incremented at the
moment the sequence point is reached.
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
Additional info on sequence points: https://stackoverflow.com/a/4176333/1938163
This question already has answers here:
order of evaluation of || and && in c
(5 answers)
Closed 9 years ago.
This question is been on my mind for a while so time to let it out and see what what you guys you have to say about it.
In C/C++ the operator precedence is defined by the C specification but as with everything there may be backdoors or unknown / not well known things that the compilers may employ under the name of 'optimization' which will mess up your application in the end.
Take this simple example :
bool CheckStringPtr(const char* textData)
{
return (!textData || textData[0]==(char)0);
}
In this case I test if the pointer is null then I check the first char is zero, essentially this is a test for a zero length string. Logically the 2 operations are exchangeable but if that would happen in some cases it would crash with since it's trying to read a non-existent memory address.
So the question is : is there anything that enforces the order of how operators/functions are executed, I know the safest way is to use 2 IFs below each other but this way should be the same assuming that the evaluation order of the operators never ever change.
So are compilers forced by the C/C++ specification to not change the order of evaluation or are they sometimes allowed to change the order, like it depends on compiler parameters, optimizations especially?
First note that precedence and evaluation order are two different (largely unrelated) concepts.
So are compilers forced by the C/C++ specification to not change the order of evaluation?
The compiler must produce behaviour that is consistent with the behaviour guaranteed by the C language standard. It is free to change e.g. the order of evaluation so long as the overall observed behaviour is unchanged.
Logically the 2 operations are exchangeable but if that would happen in some cases it would crash
|| and && are defined to have short-circuit semantics; they may not be interchanged.
The C and C++ standards explicitly support short-circuit evaluation, and thus require the left-hand operand of the &&, ||, or ? operator to be evaluated before the right-hand side.
Other "sequence points" include the comma operator (not to be confused with commas separating function arguments as in f(a, b)), the end of a statement (;), and between the evaluation of a function's arguments and the call to the function.
But for the most part, order of evaluation (not to be confused with precedence) is implementation defined. So, for example, don't depend on f to be called first in an expression like f(x) + g(y).