Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: Expression sequencing query
Message-ID: <7220@utzoo.UUCP>
Date: Fri, 10-Oct-86 14:31:34 EDT
Article-I.D.: utzoo.7220
Posted: Fri Oct 10 14:31:34 1986
Date-Received: Fri, 10-Oct-86 14:31:34 EDT
References: <760@oakhill.UUCP> <111@titan.UUCP> <468@jc3b21.UUCP> <160@geac.UUCP>, <390@sdchema.sdchem.UUCP>
Organization: U of Toronto Zoology
Lines: 20
Keywords: Bugs

> For numerical calculations it would be very nice to be able
> to specify order.  Breaking up the expression into individual ones is  n o t
> a viable option...  I think the best solution would be a unary operator
> with syntax like 'return', so that the compiler would have to respect
> parentheses for order of evaluation of the following statement...
> 	
> 	respect	<expr> ;

X3J11 has not done quite this, but they have provided a way to specify a
"fence" within an expression.  The unary plus operator, originally provided
for relatively minor reasons of consistency, also does this job.  To force
the parenthesized addition in "(a+b)+c" to be done first, write "+(a+b)+c".
(Unary operators have higher priority than binary, so "+(a+b)" is an operand
of the last "+".)  The official definition of the effect is something like
"inhibits regrouping of subexpressions within its operand with subexpressions
outside it".  I can't say that I am in love with the syntax, but the facility
is there.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry