🚀 go-pugleaf

Jerry Coffin wrote:
> 
> jcoffin@rmii.com (Jerry Coffin) wrote:
[..snip..]
>  Consider a real example of unspecified behavior:
> 
> >       a = b + c + d;
> 
> [ article body that didn't fit the example _at__all_  elided ]
> 
> Okay, the order of evaluation here is unspecified.  Depending on
> circumstances, we may even be able to detect differences due to
> different orders of evaluation. (e.g. all are doubles, c and d are both
> much smaller than b.  Each of c and d being added to b might
> individually have no effect, but adding c and d first might produce a
> number large enough to affect the value of b.)
> 
> However, despite the fact that this is unspecified behavior, as long as
> the magnitudes are such that overflow is impossible, the compiler has no
> option to produce code that blows up or causes other behavior unrelated
> to adding some numbers together.  It's only leeway in the matter may, at
> most, cause a slightly different numerical result.

Two comments:

If b,c and d above are large then you could get overflow or not depending
on the order of evaluation. So you could get crash and burn directly or not
depending on order of evaluation.

If the order of evaluation can change the result of a==b (or something
similar) then it could produce arbitrarily large changes in execution path.

You are correct above if you are saying that many users will not care about
that change. You are correct in saying that the compiler should be free to
choose whatever order of evaluation it wants unless you insert parentheses.
Dismissing the difference as "a slightly different numerical result" sweeps
a little too much under the rug though, IMHO.

Steve Karmesin


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]