A C++ Problem

[Kevinphp7]

n=5; x=0;

x= --n + --n;


x= ; ?

Which is the final value of X ?

---> No loop.

[Disch]

It's undefined. X could be anything.

[Kevinphp7]

Why @Disch ?

Are you sure ?

[mutexe]

because of line 3. if I saw that in production code I'd have to throw the developer off a tall building.

http://stackoverflow.com/questions/949433/why-are-these-constructs-using-undefined-behaviour

[Kevinphp7]

@mutexe,

Why?

The correct result is 7.

[doug4]

The "intended" result may be 7. However, the behavior is undefined, so there is no "correct" result.

The most likely results might be 7 or 6 depending on how the compiler decides to implement the prefix decrementors. And I could see how a compiler might come up with 8. Any of them could be "correct". Actually, because the behavior is undefined, any value coming out would be correct.

Did you read through the link that mutexe provided? The simple answer is, don't mix multiple increment/decrement operators (prefix or postfix) of the same variable or a increment/decrement operator with an assignment to the same variable. Just don't.

[mmw]

@hello

I won't throw anyone 8-) ; but I might have strong words ;

to the original poster ; this is undefined because it's totally up to the compiler-rules to decide the order of operands ; there is no clear rule about when the addition happens neither the two decrements ; is it a (volatile construct) ? don't know. (see @doug4 comment about 8 result),

it might "work as you are expecting" in a scripting language, despite the platform ; because the interpreter applies the same rules and translations ; but I could not say if it's true for all scripting languages; the result might be different in php, bash or python ; like in this case according to the compiler.

[mmw]

@Kevinphp7 we are still waiting for you e.g that you amend yourself, and accept you were wrong, that's the line drawn between being a geek and a nurd :O

morality: don't dead lock the mutex it might throw you ; deadbeaf is fatal 8-D

[mutexe]

The correct result is 7.

You didn't read that link I pasted in I guess..

it might "work as you are expecting" in a scripting language, despite the platform ; because the interpreter applies the same rules and translations ; but I could not say if it's true for all scripting languages; the result might be different in php, bash or python ; like in this case according to the compiler.

what are you talking about? Why are you even mentioning scripting languages in this thread's context?

[mmw]

Hello,

I mentionned it as an example which perfectly fits the situation ; in one environment it might "work as expected" in another nope ; a compiler, in this example can be seen like an interpreter of op-code ; different env / different rules.

An interpreter is not tight to the platform but the differences between two scripting-languages and their interpreters can illustrate the same differences you can find in a compiler implementation [as well as, its different targets, another story] despite the language compiled being the "same". But, it is very true also that the OP nickname gave me some inspirations 8-)