() ignored in some expressions

diamond@tkovoa diamond at tkou02.enet.dec.com
Thu Apr 12 16:54:25 AEST 1990


In article <1458 at tkou02.enet.dec.com>, diamond at tkou02.enet.dec.com (diamond at tkovoa) writes: 
[Maybe I should apply for a legal change-of-name?  @tkovoa indeed,
thanks computer.]

>>> This whole discussion concerns whether () may be ignored.  In ANSI,
>>> for "(a + b) + c", the () must be obeyed.  Now the compiler must
>>> add a and b first, then add c, or else do something that has the
>>> same exact behavior.

In article <1284 at sdrc.UUCP> scjones at sdrc.UUCP (Larry Jones) writes:

>>That's a common misconception, but it's just not true.  
>>There's an explicit example of this in section 2.1.2.3

In article <1990Apr12.013616.9924 at murdoch.acc.Virginia.EDU> gsh7w at astsun.astro.Virginia.EDU (Greg S. Hennessy) writes:

>It seems to me that the two of you are saying the same thing. Why is
>what diamond at tkovoa different from what is in 2.1.2.3?

The order of evaluation (execution-time sequence of operations) used to
be less strictly related to the precedence of binding (compile-time
syntactic grouping).

I was misled by the common citation of the new order-of-evaluation rules
as "respect for parentheses".  Section 3.3 almost states the correct rule,
but leaves things a little cloudy.  If section 3.3 really implies what
everyone says it does, then it ALSO implies that ++a updates a (i.e. its
side effect completes) before the resulting value is used in an expression.
Haven't seen anyone share this opinion yet, so interpretations of 3.3
seem cloudy indeed.

2.1.2.3 indeed seems to affect this issue as well.  It says "behavior",
not just "binding".  However, it does not clear up 3.3's clouds.

The index entry for "order of evaluation of expression" unhelpfully omits
section 2.1.2.3 as well.  (To be pedantic, to answer your question, this
is why I said something different from section 2.1.2.3.)

-- 
Norman Diamond, Nihon DEC     diamond at tkou02.enet.dec.com
This_blank_intentionally_left_underlined________________________________________



More information about the Comp.lang.c mailing list