Re: Same code and different result, Why?

"Tommy" wrote:
[...] 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.

I agree with Nathan on this. I can't say with such confidence that
MS compiler stands out in any significant way when we speak about
order of evaluation. I should admit that I have less experience
than you, but cannot recall any consistency regarding undefined
order of evaluation among other non-MS compilers. I was taught
long time ago not to rely on such constructs because they depend
on the mood of optimizer.

Moreover, Stroustrup talks about this very case in the article I
posted:

<quote>
int i = 10;
int j = ++i + i++; // value of j unspecified
....
The value of j is unspecified to allow compilers to produce
optimal code. It is claimed that the difference between what can
be produced giving the compiler this freedom and requiring
"ordinary left-to-right evaluation" can be significant. I'm
unconvinced, but with innumerable compilers "out there" taking
advantage of the freedom and some people passionately defending
that freedom, a change would be difficult and could take decades
to penetrate to the distant corners of the C and C++ worlds.
</quote>

I think the common practice you refer to is not that common after
all. With today's abundance of CPU architectures the registers
jugglery can be found in every decent optimizer, which makes
undefined order of evaluation even less common and more undefined.

Alex


.

Relevant Pages

  • Re: sequence points and the execution model
    ... the evaluation order in C, rather than gratifying their egos by making ... I don't believe that this is such a useful freedom to the implementors any ... in the compiler. ... pointers are restrict-qualified! ...
    (comp.lang.c)
  • Re: Sun forte7 f90 bug
    ... >> each and every occurence of the common block named DATUMS, ... I assumed that the compiler writers, in their infinite wisdom, ... >> issue with a number of other experienced fortran programmers. ...
    (comp.lang.fortran)
  • Re: If you got to choose the syntax, what would you do?
    ... pretty common these days, so I should put in a few thoughts. ... Do they execute the tokens serially from the stream or do they ... execute tokens from the outside world, or put a Forth compiler in there ...
    (comp.lang.forth)
  • Re: A C showstopper
    ... behalf of the fiduciary interest of compiler vendors and not for the ... Your job was to DEFINE a common C and write a free reference compiler ... criticism, you made any hard question undefined. ...
    (comp.lang.c)
  • Re: Sun forte7 f90 bug
    ... The compiler told you what it did. ... match up the common. ... Certainly it won't change in already compiled routines. ... > compiler did to separate occurences of it when it found nothing to ...
    (comp.lang.fortran)
Loading