Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!cs.utexas.edu!uunet!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: learning C (was: Re: ambiguous ?)
Message-ID: <2523@munnari.oz.au>
Date: 25 Oct 89 06:00:56 GMT
References: <225800228@uxe.cso.uiuc.edu> <14117@lanl.gov>
Sender: news@cs.mu.oz.au
Lines: 40

In article <14117@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> This _discussion_ is about whether C has _efficient_ means of forcing
> evaluation order in _several_ contexts (the first was the order of
> argument evaluation in a function call).

It is impossible to conduct such a discussion.  A language may have
complex or concise or clear or confusing or direct or indirect means
of expressing something, but efficiency is a property of implementations,
not of languages.

>  Temporary variables are
> _not_ an efficient solution (unless they are optimized out - something
> C compilers are rarely clever enough to do).

This is confusing two levels:  languages and implementations.
Heck, "a := a+1" should be efficiently implemented, but I know of one Ada
compiler for the NS32000 that generates 8 instructions for it (not a
commercial product; it was reported in SP&E 1987; they hadn't put the
peephole optimiser in yet).  If C compilers X, Y, and Z don't optimise
out temporary variables, complain about compilers X, Y, and Z, not about
C.  If the vendors of compilers X, Y, and Z independently explain that
the optimisation is hard because of property P of the language, complain
then abou property P of the language.

> Temporary variables also
> have a negative impact on readibility (by diffusing the 'locality' of
> specific operations).

Well, that depends.  To start with, temporary variables have the great
merit of being a familiar means.  That's how you force argument
evaluation order in Algol 60, Pascal, Ada, Fortran (66, 77, 8X), Modula,
Lisp, Simula 67, ...  The technique also has the merit of making the
order of evaluation obvious.  There is a further point that if expression
E1 has to be evaluated before expression E2, it makes it a whole lot
simpler to explain in the comments *why* E1 has to be evaluated before
E2 if you have names for the results.

Finally, I was taught years and years ago that a complicated expression
should be broken up into medium-sized pieces (such as could be given
meaningful names) *to make it more readable*.