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

chase@centerline.com (David Chase) writes:
> 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).


In practice, the presence of side effects in expressions is USUALLY
harmless, as long as there is not more than one side effect on the
same data entity. Having to assume a strict left to right sequencing
on operation involving side effects can greatly affect the degree of
optimization possible, particularly on compilers for RISC
architectures which place a high premium on maintaining values in
registers as much as possible.


Keep in mind that to maintain strict left to right (or any other
canonical) semantics on side effects means that any operation which
MIGHT result in a side effect must then produce a sequence point,
resulting in smaller optimizable chunks and fewer opportunities for
instruction reordering.


> 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.


Not really true. Even if a variable which is subject to side effects
lives only in a register, constraining the order of side effects can
influence the efficient use of registers by forcing additional values
to be preserved.


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


It could certainly be argued that specifying the order of side
effects would minimize hidden defects. And if the language
definition specifies such semantics, the compiler must not permit
optimizations that violate those semantics, regardless of efficiency
issues. But the fact is, compiler efficiency is not the primary
reason for an unspecified order of evaluation.


The real reason is that the standard did not shape the development of
the language, it codified existing practice. And there are too many
compilers out there that evaluate operands in various orders,
including some whose order depends on what occurs during
optimization. Changing the order of evaluation for many of these is
more than a minor fix, would instead require massive redesign and
rewrite. So the industry rejected any specification of the order of
evaluation.


Everyone, including me, has twenty-twenty hindsight when it comes to
saying how a mature language SHOULD have been designed. C has its
strengths and weaknesses like any language. And perhaps some of
these are worth changing, but it's important to first ask "What would
be the impact on existing users of the language, and on existing
compiler implementations?"


In the case of a seemingly esoteric change like specifying the order
of evaluation of operands, the cost to users should be 0 (any code
that would be affected adversely is already incorrect and subject to
failure), but the cost to existing compiler implementations is
potentially staggering.


--
det@phlan.sw.stratus.com |
(Dave Toland) |
--

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