ambiguous ?
Jim Giles
jlg at lanl.gov
Tue Oct 24 07:42:20 AEST 1989
>From article <6637 at ficc.uu.net>, by peter at ficc.uu.net (Peter da Silva):
> [...]
> This has nothing to do with function calls that have side effects. We're
> talking about evaluation order of arguments... expressions that have side
> effects being used in arguments to function calls.
I've already discussed this case in THREE previous submissions! If the
_expressions_ used as arguments have dependent side effects, if a compiler
is capable of optimizing the order of argument evaluation in any useful
way (that is, both correct and efficient), than that compiler is _also_
capable of detecting the dependencies and enforcing some fixed evaluation
order on them. The C standard would loose _NO_ useful optimization
potential by specifying the _effective_ order in which arguments were
to be evaluated.
> You may be confused because in Fortran the only way an expression can have
> side effects is if it involves a function call.
I am obviously _not_ confused in that manner. Everyone seems to assume
any opponent of C must be some reactionary neanderthal committed to
Fortran. Anyone who reads comp.lang.fortran can vouch for the fact
that I find a good number of things wrong with Fortran! In fact, what
I really want is for programming language technology to _advance_!
Neither C nor Fortran are advances. There are things to be learned
from both of them though - mistakes as well as good ideas. I can't
understand the "reactionary neanderthal" attitude of many C programmers
who seem to feel that there's no way to improve their language and
no point in discussing its faults.
> [...]
> DATA I /0/
> J = I * GETCH(5)
> J = 0 * GETCH(6)
> Is this legal?
> Is it guaranteed that GETCH(5) will be evaluated?
> Is it guaranteed that GETCH(6) will be evaluated?
> C makes these guarantees.
However, C does not guarantee that the following two functions will
be evaluated:
if (getch(5) && getch(6)) {...}
Once again, your assumption that I believe Fortran to be perfect is
not correct. As I've already pointed out, it should be possible to
explicitly specify whether a function has side effects and the
language definition should be scrupulously specific about the evaluation
order (as well as _whether_ they are evaluated) in the presence of
such side effects.
More information about the Comp.lang.c
mailing list