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

jthill@netcom.com (Jim Hill) writes:
> I'd say leave it [order of evaluation] unspecified. If a programmer needs that
> level of control they can just write them as separate statements in sequence.
> I'll go out on a limb and assert that 99+% of all argument lists are completely
> unaffected by order-of-evaluation, and that the ordering would be better reserved
> for implicit doc.


Perhaps I, too, have become a crank on this subject, but I haven't
seen anyone point out a benefit that any programmer actually derives
from ambiguous order of (side-effect-containing) expression evalation
(in practice, not in theory). Over the years, people have claimed
that this permits generation of more efficient code. In my
experience, which includes writing C, implementing C, optimizing C,
and using C as an intermediate language, I don't think I've seen
anyone actually take advantage of this potential optimization (*),
and in years of reading papers, I've never read of any measured
benefit in a real compiler. In fact, the compilers I've worked on
take the approach that the front-end is responsible for the order,
and the optimizer preserves the order of all apparent side-effects.
Furthermore, current trends in computer implementation seem to
minimize the cost of non-memory instructions like parameter shuffling
(even if the parameters are on a stack, that stack is almost
certainly cache-resident), so these benefits (if there are any) will
only be reduced in the future.


(*) Do, please, understand that I am talking about the order of
evaluation of apparent side-effects, and not pure expression
evaluation. The compiler should be free to reorder obviously pure
expressions as much as it wants. There are also benefits obtained by
permitting reordering of floating point arithmetic in
dependence-driven transformations, which can (pedantically speaking)
change the meaning of a program. However, in that case the benefits
can be substantial, and the changes to program meaning are much more
constrained.


Thus, I conclude that there are no benefits to leaving the order of
(side-effect-containing) expression evaluation unspecified.


Are there any costs? Yes. People MAY write code that depends on the
order in which side-effects occur, and they may not know it, and
their compiler may not detect it. This MAY lead to portability bugs,
which at minimum costs the money required to test for these
portability bugs.


This is especially true for complicated languages like C++. I'm
hoping to convince our rep to the standards committee to make a case
for a well-defined order of evaluation, though I have little hope
that it would be well-received. (Of course, I'd also like them to
stamp out a lot of other stupid ambiguities, like those relating to
temporary generation.)


David Chase
--

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