Associativity of operators in c

[compubaba]

What exactly is meant of by associativity(right to left / left to right) mentioned on p53 of K&R 2nd edition. The book mentions that in
X= f() + g()
f may be evaluated before g or vice versa . But in the table it has been mentioned that () has the highest precedence and left to right associativity. Why isn`t that it is guaranteed that f is evaluated first.
If this is not the right place to apply the associativity rules , please help me with an example so as to clarify the things.

I have something in my mind as an explanation of this , but first I want to hear all your views . Plzzzzzz.....

[ithelp]

You took a wrong example
a + b + c will be interpreted as (a+b) +c if left to right associativity is assumed.

[Dave Sinkula]

http://c-faq.com/expr/precvsooe.html

[compubaba]

Agreed that a+b+c is (a+b)+c if left to right associativity is assumed .
Do u mean that associativity rules are applied if an operand competes for two operators of same precedence simultaneously.

Take an example
f() + g() * h()
When I want to evaluate this expression first I will go for function call as it has highest precedence but then why should I not apply the associativity rule because it imposes an order of evaluation of operands. Am I right??

Can someone give an example in which associativity rules are applied for the function call operator ??

[9868]

Agreed that a+b+c is (a+b)+c if left to right associativity is assumed .
Do u mean that associativity rules are applied if an operand competes for two operators of same precedence simultaneously.

Take an example
f() + g() * h()
When I want to evaluate this expression first I will go for function call as it has highest precedence but then why should I not apply the associativity rule because it imposes an order of evaluation of operands. Am I right??

Can someone give an example in which associativity rules are applied for the function call operator ??

Yes, associativity is applied only if you have operators of same precedence in the precedence table.
In you case f()+g()*h(), g()*h() will be done first coz * has higher precedence than +, but which one of the two g() and h() will be called is entirely dependent on the compiler. Take a look at this example.

int a=5,b=6,c,d;
c=a,b;
d=(a,b);
printf("%d\n%d",c,d);

Check the output and make this clear.

[Salem]

> In you case f()+g()*h(), g()*h() will be done first coz * has higher precedence than +,
> but which one of the two g() and h() will be called is entirely dependent on the compiler.
Read Dave's link, there is nothing which says that f() won't be called first (or second for that matter).

t1 = f();
t2 = g();
t3 = h();
t4 = t2 * t3;
answer = t1 + t4;

Is just as plausible as any other evaluation.

Precedence defines the order in which intermediate results are combined, but says nothing about the order in which the intermediate results themselves are arrived at.

Throw in some CSE and bits of your overall expression could be all over the place.

[9868]

> In you case f()+g()*h(), g()*h() will be done first coz * has higher precedence than +,
> but which one of the two g() and h() will be called is entirely dependent on the compiler.
Read Dave's link, there is nothing which says that f() won't be called first (or second for that matter).

t1 = f();
t2 = g();
t3 = h();
t4 = t2 * t3;
answer = t1 + t4;

Is just as plausible as any other evaluation.

Precedence defines the order in which intermediate results are combined, but says nothing about the order in which the intermediate results themselves are arrived at.

Throw in some CSE and bits of your overall expression could be all over the place.

Ahem..............You mean to say that f() will be called first in f()+g()*h(). Ok here's another example:
a=f1()*f2()+f3();
according to you which one of the 3 functions will be called first.

[Salem]

> according to you which one of the 3 functions will be called first.
No idea, it doesn't matter, I don't care.
That's for any individual compiler writer to decide. It's not in the language spec to define such things.

* happens before +, which in turn happens before =
That's all you have to go on, anything else which happens is up for grabs.

> You mean to say that f() will be called first in f()+g()*h().
Read - MAY BE CALLED FIRST.

If your code depends on it being called first (or last), then your code is broken - no ifs, buts or maybes.

[9868]

> according to you which one of the 3 functions will be called first.
No idea, it doesn't matter, I don't care.
That's for any individual compiler writer to decide. It's not in the language spec to define such things.

* happens before +, which in turn happens before =
That's all you have to go on, anything else which happens is up for grabs.

> You mean to say that f() will be called first in f()+g()*h().
Read - MAY BE CALLED FIRST.

If your code depends on it being called first (or last), then your code is broken - no ifs, buts or maybes.

Dont you think there is no chance of f() getting called first, coz the precedence of * is higher than +, so either of g() or h() will be called first.

[9868]

> according to you which one of the 3 functions will be called first.
No idea, it doesn't matter, I don't care.
That's for any individual compiler writer to decide. It's not in the language spec to define such things.

* happens before +, which in turn happens before =
That's all you have to go on, anything else which happens is up for grabs.

> You mean to say that f() will be called first in f()+g()*h().
Read - MAY BE CALLED FIRST.

If your code depends on it being called first (or last), then your code is broken - no ifs, buts or maybes.

Dont you think there is no chance in hell that f() will be called g() or h(), coz * has higher precedence than +. If f() is called first than, the whole purpose of precedency is lost.

[Aia]

Dont you think there is no chance in hell that f() will be called g() or h(), coz * has higher precedence than +. If f() is called first than, the whole purpose of precedency is lost.

Precedence doesn't have any hold on them, since that behavior is undefined.

[Salem]

> If f() is called first than, the whole purpose of precedency is lost.
Oh man, learn to read.

f() called first, result stored in temp1 - have we done + or * yet - no.
g() called next, result stored in temp2, have we done + or * yet - no.
h() called last, result is still in a register.
Multiply register with temp2 - woohoo!, we did * first.

Sure, you might be thinking
call g(), result in temp1, call h(), multiply by temp1, store in temp2
Then call f(), add temp2 and store result.

Different - yes
Same result if all the functions are free of side effects - yes
This order is mandated by the standard - nope.
Undefined outcome if any of the functions have overlapping side effects - you bet your ass it's undefined!.

[9868]

> If f() is called first than, the whole purpose of precedency is lost.
Oh man, learn to read.

f() called first, result stored in temp1 - have we done + or * yet - no.
g() called next, result stored in temp2, have we done + or * yet - no.
h() called last, result is still in a register.
Multiply register with temp2 - woohoo!, we did * first.

Sure, you might be thinking
call g(), result in temp1, call h(), multiply by temp1, store in temp2
Then call f(), add temp2 and store result.

Different - yes
Same result if all the functions are free of side effects - yes
This order is mandated by the standard - nope.
Undefined outcome if any of the functions have overlapping side effects - you bet your ass it's undefined!.

Dont get too excited buddy. It would have been much simpler if you told me that way early. And please be more patient next time you deal with a C learner like me, you bet your ass you're not the only one who knows all this and be cool next time.

[Salem]

I said nothing different than my FIRST post in this thread.
How much earlier would you have liked it? :icon_rolleyes: