Re: Order of argument evaluation in C++, etc.

eggert@twinsun.com (Paul Eggert) writes:
> In my opinion, order-of-evaluation is the most important problem
> area in the C Standard proper. Other language standards since Algol 68
> (e.g. Ada, Fortran, PL/I, Scheme) have addressed this issue more clearly.
> Future C and C++ standards should do so as well.


Having been a member of the Fortran 90 standards committee, I wonder how
you could say that Fortran has addressed this "problem" more clearly than
C. Fortran gives more latitude, if anything, to reordering evaluation than
C does. In particular, in the example you gave, Fortran 90 also says the
results are undefined. (Meaning that the compiler is free to evaluate in
any order, even interleaved.)


Ada does enforce more ordering, and not surprisingly, Ada is much harder to
optimize! In my opinion, Ada went way too far the other direction.


> [1] Yes, there's a sequence point before each call and after each return,
> but the C Standard does not say that the second call's sequence point
> must come after the first return's sequence point, or vice versa.


Good!


> On the contrary, the standard explicitly gives the implementation
> permission to jumble up the evaluation of sibling subexpressions,
> so it is reasonable to interpret the standard as saying that the above
> example has undefined behavior because the sequence points of the two
> function executions can be interleaved.


I see absolutely nothing wrong with that. If you want to force a
particular order of evaluation, put the function calls in separate
statements. Period.


I don't see why this is a problem, when there's a perfectly good way to get
what you want. If the standard *did* enforce ordering, then what happens
when parallel computers become the norm and everybody's compiler is
*capable* of parallelization? Then you get no benefit from the
parallelism, because the languages everybody is using still live in the
serial execution world.


The existing situation gives programmers a way to get what they want, but
still provides room for growth in compiler optimization as the world
evolves. Even if there are no compilers who would do such an optimization
today (which is not true anyway), that doesn't mean we shouldn't provide
for it in the future, particularly when we can see a trend in that
direction now.


Remember that code written to today's language standards may live 30 years
or more. You're not doing anybody any favors by insisting that today's
standard lock everybody into 1980s computer technology.


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.