Re: Must an expression be evaluated before its value is used?

Jordan Abel wrote:
2006-05-29 <1148912548.337954.134900@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, kuyper@xxxxxxxxxx wrote:
Hallvard B Furuseth wrote:
Francis Glassborow writes:
In article <hbf.20060529kwfs@xxxxxxxxxxxxx>, Hallvard B Furuseth
<h.b.furuseth@xxxxxxxxxxx> writes
The example (and thread subject) in comp.lang.c is

x=(x=5,11)

The compiler can know what the value of the right-hand side will be
before executing x=5.
(And there is a sequence point at ",", but not at "=".)

I think that is a poor example because the compiler is allowed to
optimise away almost everything and the program cannot tell the
difference. So the 'as if' rule applies and destroys the example.

That was the idea - it might optimize away x=11 if that's done _before_
x=5.

It must evaluate x=5,11 before it can assign the result to x.

Nowhere in the standard is that said. You have in effect created
a sequence point (at the = operator) where before there was none.

No, this is not a sequence point. The standard provides no term for
what this is, but for the sake of discussing it, I'll call it an
evaluation dependency. The evaluation dependency has a consequence of
forcing the sequence point associated with the comma operator to
seperate the assignment of 5 to x from the assignment of 11 to x.
However, if none of the sub-expressions of the assignment operator had
a sequence point in it, then the side-effects of those sub-expressions
could be delayed until after the side effects of assignment itself.
That would not be the case if there were a sequence point associated
with the assignment operator, and I'm not claiming that there is.

The standard does not explicitly mention evaluation dependencies, but
they are implicit in the definitions of the operators. In 6.5.17p2, it
says "Then the right operand is evaluated; the result has its type and
value." Therefore, you cannot evaluate (determine the value of) the
comma operator without first evaluating it's second operand. In section
6.5.16.1p2 it specifies that "the value of the right operand is
converted to the type of the assignment expression and replaces the
value stored in the object designated by the left operand." Therefore,
there's an implicit evaluation dependency: the value of the right
operand can't be stored anywhere, until that value has been determined,
which is another way of saying that the right operand has been
evaluated. That value can't be stored in the correct location until the
location specified by the left operand has been determined, which is
another way of saying that the left operand has been evaluated.

I think that the reason that the standard says nothing about evaluation
dependencies is that the authors felt that it already says all that
needs to be said when it implies those dependencies. I certainly am
having trouble figuring out what wording would need to be added to make
the existence of those dependencies clearer. If, in the expression
c=a+b, a program doesn't have to evaluate both a and b before storing
it's result in c, then precisely what result is it supposed to store in
c?

I've seen arguments which suggest that it would be permissible for an
implementation to generate code which determines the value of a, then
the value of b, calculates their sum, then stores the result in a
register. Then it evaluates a, evaluates b, and then moves the value
stored in the register into c. In the case where a and b are
sub-expressions that might contain sequence points and side effects,
this would be an important conclusion, if it were true. It founders on
the fact that "evaluate" means "determine the value of". Under the
as-if rule, an implementation is free to evaluate a sub-expression as
many different times as it likes, but only so long as it does so in a
way that produces the same effect as if that sub-expression were
evaluated only as and when the standard specifies that it is evaluated.
The redundant evaluations can't be used to justify ignoring the
requirements imposed by any applicable sequence points and the
definitions of the meanings of the operators that are involved.

....
If it weren't for that sequence point, the behavior would be undefined,
since you would have two assignments to x that aren't seperated from
each other by a sequence point. If you take the point of view (which I
consider to be nonsense) that sequence points are to be interpreted in
textual order rather than chronological order, then there is no
intervening sequence point, and the behavior is undefined.

There is no sequence point intervening in either direction either
textual or chronological between the RHS of the assignment operator and
the assignment itself.

Agreed - I never suggested otherwise.What I said is that there is a
sequence point (the one associated with the comma operator) which
seperates, in strict chronological order, evaluation of the LHS of the
comma operator from the assignment itself.

.

Relevant Pages

  • Re: erase
    ... >> The increments are not supposed to occur after the function call. ... the execution sequence called sequence points, ... there is a sequence point after the evaluation of all function arguments ... the operand had before applying the operator. ...
    (microsoft.public.vc.stl)
  • Re: pointer arithmetic question.
    ... effect will be taking effect after the sequence point in this case ... before the side effect of updating the stored value of the operand. ... The semantics for assignment includes a sequenced-before ... evaluation of the assignment expression and all of its ...
    (comp.lang.c)
  • Re: Must an expression be evaluated before its value is used?
    ... properly define the ordering of sequence points. ... The evaluation order is defined by the abstract machine (even if it is ... there is a sequence point after the evaluation of the first operand. ... "2 The left operand of a comma operator is evaluated as a void ...
    (comp.std.c)
  • Re: x=(x=5,11)
    ... convert it to the type of the assignment expression without evaluting ... Sequence points define a partial ordering. ... "The order of evaluation of the function designator, ... made to modify the result of a comma operator or to access it after the ...
    (comp.lang.c)
  • Re: [C, C++] "(a=b) = c;" Illegal or Undefined?
    ... It is an assignment. ... > referred to by the left operand. ... C is based on a "strict evaluation" scheme: ...
    (alt.comp.lang.learn.c-cpp)