> There were two others on this thread, but I was interrupted by a
> 'work break' so I hit the 'D' key.
>
> In the case of:
>
> a = b + c + f(d);
>
> ... f(d) must be evaluated first because of the precedence
> of the () operator.
Eh? Precedence is just a parsing issue whose purpose is to save
parentheses.
> It is important to understand what f(d) really means. It
> means to evaluate 'd' using an object called 'f'. F is not
> necessarily a function. It could be a macro.
>
> The closing of a parenthesis means "evaluate the objects
> between the opening and closing parenthesis". In some texts,
> "()" is called the evaluation operator. Each time an
> evaluation operation is complete, a sequence-point is
> established. This is the only reason why objects are
> evaluated before a function is called. The "()" operator
> forces this.
No, no, no. As it happens, the precedence of function application in c is
not very important, and is only required to distinguish between a+b(c)
being a+(b(c)) or (a+b)(c).
> This is also the reason why calling a function through a
> pointer must use 'extra' parenthesis:
>
> r = (*f)(a);
>
> ... since
>
> (*f) closes the parenthesis
>
> ... and
>
> (a) closes the parenthesis
>
> ... evaluation occurs left-to-right as:
>
> de-reference pointer 'f', then evaluate 'a' using the
> object addressed by it.
You seem to be confusing parsing and evaluation.
> If we didn't have the extra set of parenthesis as:
>
> c = *f(a);
>
> ... we tell the compiler to evaluate 'a' using object 'f'
> which has not been de-referenced yet, which will not work.
> FYI, some compilers allow c = f(a), where 'f' is a pointer.
> This is bogus and helps prevent 'C' writers from learning
> what they are really doing.
>
> When seeing ONLY:
>
> a = b + f(c);
>
> ... the compiler must evaluate 'c', using object 'f', first
> because '()' has the highest precedence of any 'C' operator.
Evaluation and precedence are independant.
> When seeing:
>
> a = b + c + d;
>
> ... the compiler may still not legally evaluate the objects
> in any order because of associativity, but many/most do.
> Optimization is not yet part of the 'C' standard. When
> attempting to optimize code, certain standards are broken as
> long as the code is likely to work.
The left associativity of the '+' operator is a parsing thing. It means
that a+b+c gets parsed as (a+b)+c, and no a+(b+c). That is all. '+' is
associative, so we can be pretty sure that these are the same. c makes
no guarantees about evaluation order of associative, symmetric operators;
(a=0)+a+(a=1) could evaluate in any of a number of ways, and leave a equal
to 0 or 1 afterwards.
> Everything makes sense once one understands the '()' operator.
Keep reading, you might ;-)
Matthew.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu