Re: Same code and different result, Why?

Alex Blekhman wrote:

and best from what I tell, its a MS Compiler issue only - excused with the documented sequence point idea.

No, it is undefined for all other compilers, as well. The notion of sequence point is common for all C/C++ compilers. However, the exact place where sequence point occurs may vary from vendor to vendor.

I think that B. Stroustrup answerd to you claim better than I could:

"Why are some things left undefined in C++?"
http://www.research.att.com/~bs/bs_faq2.html#undefined


Alex, you missed the point. I'll try it this way.

In every technology, protocol, what have you, when they is a lack of consensus, in principle, you use the best practice. This is part for the course for the technology you are using right now, the compiler, including the news groups protocol NNTP (RFC 977) you are using, as well as, and especially in Email (RFC 5321) technology.

In all cases, it is not that behavior is not defined, it is indeterministic, there could be many behaviors but generally well defined set of behavior. So in principle, there is lack of consensus for what is the correct behavior - which one is deemed "more" correct.

My point, and I strongly believe this from a functional programming statement, which many will argue that C is quite indeed a functional programming model, that given all the different constructs you can come up that emulate the same idea, all of them, produce the same result but the one Microsoft choose for its compiler for the simplest construct:

x = x++ + y++;

So while we all agreed and acknowledge that this is generally considered an axiom that may produce different results depending on the compiler, when you look at the BCP (Best Current Practice) that exist for the possible results, the MS solution is the least common one.

BCP is something one must be aware of otherwise when they do confront situations like this and guaranteed that you will, they will generally get it wrong and not be compatible with the rest of the world.

---
.

Relevant Pages

  • Re: Derived data types vs computation time
    ... >> or not, of SEQUENCE in the definition, the compiler may or may be forced ... the standard has no reason at all for the compiler ... Even for most sequence types, the standard does not really mandate ...
    (comp.lang.fortran)
  • Re: Warning: The structure contains misaligned fields
    ... since SEQUENCE derived types may be used in COMMON ... feasible for the compiler to automatically re-order to avoid alignment ... And IVARin this program unit must be storage associated with VAR1 ...
    (comp.lang.fortran)
  • Re: Function order.
    ... particular ordering (sequence of operations). ... the compiler actually used. ... Schedule a copy the value found into the location found ... Here we "schedule an increment and produce the previous value", ...
    (comp.lang.c)
  • Re: Fixpoint for LZH
    ... > might (with a particular compiler) indeed get a fixed point. ... "0123456789", I got a strictly increasing sequence of sizes, as follows: ... for example, in that Stuffit for Macs if memory serves right, never ...
    (sci.math)
  • Re: extended operators
    ... between the sequence point X and the last sequence point. ... Perhaps it should be a macro, defined in a new header, that expands to some implementation-defined expression (possibly involving compiler magic). ... So you'd mandate specific restrictions on generated code in the presence of calls to _carry, even if the compiler is able to prove that it can perform an optimization without changing the effect? ... The ``result'' member is set to the sum of x and y; unlike an ordinary "+" operator, the result is well defined even on overflow. ...
    (comp.std.c)