shahrine99
asked on
expression
here is the following statement
i = 5;
j = i++ - ++i;
What are the possible values of j in C++?
My guess would be 0 because if I increase i then subtract i then i should get 0, am I right?
i = 5;
j = i++ - ++i;
What are the possible values of j in C++?
My guess would be 0 because if I increase i then subtract i then i should get 0, am I right?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>The answer is ambiguous, but saying it is implementation defined what happens is a far cry from saying it can be anything.
Yes, it is a bit of a strech to truely believe that it can equal to anything.
However, the point I'm trying to make, is that you should not care what it equals to, because you should avoid using implementation defined code, if it's not absolutely required.
Clearly this type of code usage is not absolutely required, and you can change the code to give you well defined behavior, instead of implementation defined behavior.
However, technically speaking, implementation defined means the implementation can do anything it wants, and therefore the results can be anything the implementation desires it to be.
I'm not saying any compiler will do this, but I am saying that a compiler can do it, and still be considered compliant to the C++ standard.
Yes, it is a bit of a strech to truely believe that it can equal to anything.
However, the point I'm trying to make, is that you should not care what it equals to, because you should avoid using implementation defined code, if it's not absolutely required.
Clearly this type of code usage is not absolutely required, and you can change the code to give you well defined behavior, instead of implementation defined behavior.
However, technically speaking, implementation defined means the implementation can do anything it wants, and therefore the results can be anything the implementation desires it to be.
I'm not saying any compiler will do this, but I am saying that a compiler can do it, and still be considered compliant to the C++ standard.
So there you have it.
FYI:
A good example of why you should not use implementation defined behavior, is the modification of a string literal.
Example:
char* data = "Hello World";
strcpy(data, "Good by");
The above code results in implementation defined behavior.
Many years ago, before VC++ 6.0 came out, many season C++ programmers continued to warn developers about using this type of code.
However, since VC++ 5.0 happly ran above code with no runtime errors, many developers continued to use such implementation defined code.
When VC++ 6.0 came out, it did not produce the same behavior, and infact it causes a runtime error with above code.
So developers who try to compile the same code in VC++ 6.0, whould get a runtime error, when they previously did not.
So when you're dealing with implementation defined code, you not only have to worry about how the code will work from one compiler to the next, but you also have to worry about how the code will work from one version of the compiler to the next.
Even though VC++ 5.0 and VC++ 6.0 have different results with the above code, both are considered compliant with the standard with their results.
When developers first started complaining about this issue, one of the first questions they asked, was which compiler is right (5.0 or 6.0)?
And the answer is both are right, because they can do anything they want with undefined behavior.
A good example of why you should not use implementation defined behavior, is the modification of a string literal.
Example:
char* data = "Hello World";
strcpy(data, "Good by");
The above code results in implementation defined behavior.
Many years ago, before VC++ 6.0 came out, many season C++ programmers continued to warn developers about using this type of code.
However, since VC++ 5.0 happly ran above code with no runtime errors, many developers continued to use such implementation defined code.
When VC++ 6.0 came out, it did not produce the same behavior, and infact it causes a runtime error with above code.
So developers who try to compile the same code in VC++ 6.0, whould get a runtime error, when they previously did not.
So when you're dealing with implementation defined code, you not only have to worry about how the code will work from one compiler to the next, but you also have to worry about how the code will work from one version of the compiler to the next.
Even though VC++ 5.0 and VC++ 6.0 have different results with the above code, both are considered compliant with the standard with their results.
When developers first started complaining about this issue, one of the first questions they asked, was which compiler is right (5.0 or 6.0)?
And the answer is both are right, because they can do anything they want with undefined behavior.
>Suppose it was rewritten:
>j=i - ++i;
>i++;
>What would the answer be?
>Suppose it was written:
>int temp = i++;
>j = temp - ++i;
>What then?
Then answer will be -2;
int temp = i++; this will assign the old value 5 to temp and then increase i to 6;
j = temp - ++i; will be equivalent to
j = 5 - ++i; and this will be equibalent to
j = 5 - (Increace value of i);
and finally
j= 5 - 7 = -2