Order of evaluation (was Re^2: Turbo C 2.0 vs MSC 5.1)

[der Mouse]

In article <1989Aug9.094742.20000 at gdt.bath.ac.uk>, exspes at gdr.bath.ac.uk (P E Smee) writes:

> (Although, being paranoid, I'd also suggest that the person writing
> a/b/c/d/e should inject lots of ()s to indicate that the ordering is
> really desired.  I tend to parenthesize everything :-)  Goes without
> saying that I strongly feel that languages should honor any
> order-of-evaluation requirements which the programmer specifies using
> parens.

I agree.  The problem is telling order-of-evaluation-requirements
parens from override-operator-precedence parens.  A high percentage
(most?) of the parentheses I use, for example, are either required
syntax (as in a while loop), which don't enter into this discussion, or
needed not because order of evaluation is important but to override
default operator precedence and associativity rules.

Then there are macros.

#define islower(c) (__ctypes[(c)+1]&__CTYPE_LOWER)

#define TABLE_FOR(c) (islower(c)?ltab:utab)

....

a_table = TABLE_FOR('a'+letindex);

(Let's ignore the ASCII-dependent nature of that for the moment.)  I
would be most disappointed in any compiler that failed to
constant-merge the 'a' and the 1 simply because the expanded text,
which would read something like

a_table = ((__ctypes[('a'+letindex)+1]&__CTYPE_LOWER)?ltab:utab);

happens to have a pair of parens which contain the 'a' but not the 1,
thereby prohibiting rearrangement to bring the 'a' and 1 together.

Yet if we omit that pair of parens in the definition of islower, it
then loses big if we write, for example,

islower(usec1?c1:c2)

which would then expand to

(__ctypes[usec1?c1:c2+1]&__CTYPE_LOWER)

...oops.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu

(Curious.  Put "islower" next to "isupper" and it reads one way; put it
next to "jslower" and "kslower" and it reads entirely differently. :-)