【部分原创】标准C语言的优先级、结合性、求值顺序、未定义行为和非确定行为浅析
零. 优先级
在C++ Primer一书中，对于运算符的优先级是这样描述的：
Precedence specifies how the operands are grouped. It says nothing about the order in which the operands are evaluated.
意识是说优先级规定操作数的结合方式，但并未说明操作数的计算顺序。举个例子:
6+3*4+2
如果直接按照从左到右的计算次序得到的结果是:38，但是在C/C++中它的值为20。
因为乘法运算符的优先级高于加法的优先级，因此3是和4分组到一起的，并不是6与3进行分组。这就是运算符优先级的含义。
一. 结合性
Associativity specifies how to group operators at the same precedence level.
结合性规定了具有相同优先级的运算符如何进行分组。
举个例子:
a=b=c=d;
由于该表达式中有多个赋值运算符，到底是如何进行分组的，此时就要看赋值运算符的结合性了。因为赋值运算符是右结合性，因此该表达式等同于(a=(b=(c=d))),而不是(a=(b=c)=d)这样进行分组的。
同理如m=a+b+c;
等同于m=(a+b)+c;而不是m=a+(b+c);
在标准C语言的文档里，对操作符的结合性并没有做出非常清楚的解释。一个满分的回答是：它是仲裁者，在几个操作符具有相同的优先级时决定将哪几个操作先结合在一起。
每个操作符拥有某一级别的优先级，同时也拥有左结合性或右结合性。优先级决定一个不含括号的表达式中操作数之间的“紧密”程度。例如，在表达式a*b+c中，乘法运算的优先级高于加法运算符的优先级，所以先结合乘法a*b，而不是加法b+c。
但是，许多操作符的优先级都是相同的。这时，操作符的结合性就开始发挥作用了。在表达式中如果有几个优先级相同的操作符，结合性就起仲裁的作用，由它决定哪个操作符先执行。像下面这个表达式：
int a,b=1,c=2;
a=b=c;
我们发现，这个表达式只有赋值符，这样优秀级就无法帮助我们决定哪个操作先执行，是先执行b=c呢？还是先执行a=b。如果按前者，a=结果为2，如果按后者，a的结果为1。
所有的赋值符（包括复合赋值）都具有右结合性，就是在表达式中最右边的操作最先执行，然后从右到左依次执行。这样，c先赋值给b，然后b在赋值给a，最终a的值是2。类似地，具有左结合性的操作符（如位操作符“&”和“|”）则是从左至右依次执行。
结合性只用于表达式中出现两个以上相同优先级的操作符的情况，用于消除歧义。事实上你会注意到所有优先级相同的操作符，它们的结合性也相同。这是必须如此的，否则结合性依然无法消除歧义，如果在计算表达式的值时需要考虑结合性，那么最好把这个表达式一分为二或者使用括号。
例：
a=b+c+d
=是右结合的，所以先计算（b+c+d），然后再赋值给a
+是左结合的，所以先计算（b+c），然后再计算（b+c）+d
C语言中具有右结合性的运算符包括所有单目运算符以及赋值运算符（=）和条件运算符。其它都是左结合性。
二. 求值顺序
在C/C++中规定了所有运算符的优先级以及结合性，但是并不是所有的运算符都被规定了操作数的计算次序。在C/C++中只有4个运算符被规定了操作数的计算次序，它们是&&,||,逗号运算符(,),条件运算符(?:)。
如m=f1()+f2();
在这里是先调用f1()，还是先调用f2()?不清楚，不同的编译器有不同的调用顺序，甚至相同的编译器不同的版本会有不同的调用顺序。只要最终结果与调用次序无关，这个语句就是正确的。这里要分清楚操作数的求值顺序和运算符的结合性这两个概念，可能有时候会这样去理解，因为加法操作符的结合性是左结合性，因此先调用f1()，再调用f2()，这种理解是不正确的。结合性是确定操作符的对象，并不是操作数的求值顺序。
同理2+3*4+5;
它的结合性是(2+(3*4))+5，但是不代表3*4是最先计算的，它的计算次序是未知的，未定义的。
比如3*4->2+3*4->2+3*4+5
以及2->3*4->2+3*4->2+3*4+5和5->3*4->2+3*4->2+3*4+5这些次序都是有可能的。虽然它们的计算次序不同，但是对最终结果是没有影响的。
在C语言中有少数运算符在C语言标准中是有规定表达式求值的顺序的：
1：&& 和 || 规定从左到右求值，并且在能确定整个表达式的值的时候就会停止，也就是常说的短路。
2：条件表达式的求值顺序是这样规定的：
test ? exp1 ： exp2;
条件测试部分test非零，表达式exp1被求值，否则表达式exp2被求值，并且保证exp1和exp2两者之中只有一个被求值。
3：逗号运算符的求值顺序是从左到右顺序求值，并且整个表达式的值等于最后一个表达式的值，注意逗号','还可以作为函数参数的分隔符，变量定义的分隔符等，这时候表达式的求值顺序是没有规定的！
判断表达式计算顺序时，先按优先级高的先计算，优先级低的后计算，当优先级相同时再按结合性，或从左至右顺序计算，或从右至左顺序计算。
三. 关于函数参数的赋值顺序
1. 对于一个多参数的函数，例如：f(temp1,temp2,temp3,temp4),该函数的各个参数的压栈顺序一定是从右到左依次压栈，即：先压栈temp4，在压栈temp3，再压栈temp2，在压栈temp1；
2. 但是，当temp1到temp4是可变参数参数表达式时，就会存在不确定行为(unspecified behavior)。注意：不确定行为的定义----【在两个顺序点之间，子表达式求值和副作用的顺序是不确定的。假如代码的结果与求值和副作用发生顺序相关，我们称这样的代码有不确定的行为(unspecified behavior)。】
例1：
void f( int i1, int i2, int i3, int i4 ){
cout<< i1 << ' ' << i2 << ' ' << i3 << ' ' << i4 << endl;
}
int main(){
int i = 0;
f( i++, i++, i++, i++ );
}
该代码中，f()函数中，当temp1到temp4是可变参数，C语言标准规定了一定是先“获得了”temp1到temp4的值，然后再一次从右到左压栈；但是没有确定的是：当temp1到temp4的求值是先求哪一个值，而且求值的时候，比如：temp4 = i++; 该语句拆分为：temp4=i; 和i++; 问题是后面的i++,究竟是在执行完temp4=i后立马执行，还是执行了temp3=i++后执行，还是执行了temp1=i++;后执行， 这些方面，我们均无法确定。 这些方面，不同的编译器会有不同的处理，故而得到的结果会大不相同。
又比如以下的两个例子：
下面的加法， f1 f2 f3的调用顺序是任意的:
n = f1() + f2() + f3(); // f1 f2 f3 调用顺序任意
而函数也只在实际调用前有一个求值顺序点。所以，常见于早期 C 语言教材的这类题目，是错题：
printf("%d",--a+b,--b+a); // --a + b 和 --b + a 这两个子表达式，求值顺序不确定
四. 关于未定义行为
正是因为C++标准中没有定义它，编译器没有责任说必须怎么做，[不同编译器] 或者 [同一编译器的不同版本] 或者 [同一编辑器同一版本在使用不同编译选项时] 都可能会有不同执行结果。不相信么？那么事实说话，看个程序吧。
#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
int x=0;
x=(x++)+(++x)+(x++)+(++x);
cout<<x<<endl;
return 0;
}
VC 6.0下编译，Debug版本输出7，release版本呢？却是10!为什么呢？其他编译器也许会有更多不同答案。
另一个程序：
#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
int x=1;
x=(x++ * ++x + x-- * --x);
cout<<x<<endl;
return 0;
}
VC 6.0下编译Debug版本输出5，VS 2003下Debug版本输出2。
同时微软的编译器出来的结果都各种各样，就更不用说其他公司更多的编译器了。肯定还有更多答案，不过结果本身没有意义，C++标准没有定义这种行为，对于这种undefined behavior，编译器爱怎么做都行，而我们能做的，是避免这种情况出现。“有实力的C++程序员能以最佳状态避开未定义行为。”
最保险、最规范的做法还是，严格遵守C++标准，坚决避免一切undefined behavior。
五. 补充非定义行为和非确定行为
1. 表达式求值并不一定意味着求值过程中的副作用会同步发生！这是一个违反直觉的地方，带来了非常晦涩的语义。
2. i = (i++); 这种极度简单的表达式的行为居然是未定义的(undefined behavior)『注意“未定义行为(undefined behavior)”跟“未指定行为(unspecified behavior)”之间的重大区别。前者是对于不正确的，有毛病的程序而言，未定义行为可能是任何行为，轻则出现意料之外的结果，重则程序崩溃（崩溃还算好的，糟的就是错了还一声不吭^_^）。后者则是对于well-formed程序而言，未指定(unspecified)行为的可能性一般是有限的（例如函数参数的求值顺序就是函数参数个数的全排列种），只不过具体的实现不用在文档里说明究竟在它的实现上的特定行为是怎样的。』 顺便提一下“由实现定义的行为（implementation defined）”，这一行为跟“unspecified behavior”比较类似，都是针对well-formed程序而言，只不过后者的具体行为需要特定实现注明在文档中，让用户知道。 我们一直以为i=(i++)的行为是unspecified，即以为它至少还是well-formed程序，只不过在不同编译器上有不同结果罢了，然后结果却大谬不然，其行为是undefined，可能产生任何结果（从概念上来说，甚至可能导致程序崩溃^_^）。
3. i = (i++)这种表达式如果i是用户自定义迭代器的话，其行为却又变成了 unspecified，甚至由于这里左端表达式并没有实际的side-effect，所以其结果甚至是 定 的！这就是说，在build-in operation跟user-defined operator之间某些情况下存在着不易察觉的隐晦差别。
