
You are absolutely right1 In C / C++ the expression x+yz may be evaluated e.g. like this (assuming that x,y,z may themselves be complicted expressions):
compute T1 := x
compute T2 := y
compute T3 := T1+T2
compute T4 := z
compute T5 := T3T4
or maybe like this
compute T1 := z
compute T2 := y
compute T3 := x
compute T4 := T3+T2
compute T5 := T4T1
or many other ways, but always with the addition performed before the substraction. I.e., the evaluation order of subexpressions is not specified (implementaion dependant, subject to optimization etc.), but operator precedence and associativity fully dictate the order of operations, so that x+yz is always interpreted as ((x+y)z)  in fact on purpose because of rounding problems (i.e. because floating point addition is not associative) but that's not the only reason: even though int addition is associative, I might overload '+' in a way that is not even theoretically associative.
Strictly speaking, I'm not sure whether some compilers might in fact make at least use of comuutativity and rewrite x+yz as ((y+x)z). It's hard to tell anyway as one might simply reinterprete assembler instructions differently (is ADD eax,edx "let edx=eax+edx" or "let edx=edx+eax"?) 