I don't think you know what a sequence point is.
I don't think you know what a sequence point is.
bit∙hub [bit-huhb] n. A source and destination for information.
Originally Posted by brewbuckExactly what behaviour are you two talking about? If you are talking about the snippet from post #12, then the behaviour really is undefined, but if you are talking about order of evaluation in general, then the behaviour is unspecified.Originally Posted by Mario F.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
It's irrelevant abachler.
What matters is not foo[i++], but i = foo[i++]. The standard defines you are free to swap "sequence points" depending on your needs.
laserlight: It's in fact order of evaluation in general. That's the context of what brewbuck quoted from me.
Last edited by Mario F.; 12-29-2009 at 01:24 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
The compiler should be deterministic, but it isn't always easy to look at an expression and predict what will happen. For instance, the order in which subexpressions are evaluated may depend on things like register pressure, which you really can't discern. Changing some seemingly unrelated code on a previous or subsequent line may change the evaluation of an intervening expression, simply because the allocation of registers has changed.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
It's true that non-determinism in compilers is usually treated as a bug. Nevertheless, it happens, e.g. in LLVM/Clang we've had several bugs where some data structure (a hash or tree, usually) was sorted according to pointer values - and was thus extremely prone to change in face of the slightest change in the input. In the most recent incarnation, for example, this would change the order in which some functions were emitted in the object file. This can actually make a difference in, say, application startup performance, as the OpenOffice.org and Mozilla projects have discovered.
The other issue with undefined behavior is that optimizers tend to treat it in unpredictable ways. The effect? Internal state of the optimizer can completely change the way a statement is treated, i.e. completely unrelated code changes (in a different function, a different module even if using LTO) can change the way the statement is compiled.
Finally, undefined behavior in the C++0x execution model can be completely undefined: C++0x specifies multiple threads, and thus clearly defines what a race condition is. Programs containing race conditions are undefined, and have fun trying to duplicate the environment closely enough to get guaranteed identical runs from such programs.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law