前一阵子一个偶然的机会，在soloist的blog上（http://blog.csdn.net/soloist）看到一篇关于C/C++中的一个十分历史悠久的问题的讨论，即表达式求值的问题。说实话这个问题着实不新鲜了，被所有论坛提出过无数次，无非就是表达式求值顺序不确定的问题嘛。所以我也就没太在意，soloist那里吵翻了天，说什么的都有，热闹非凡。
当时我就当复习一下，想看看标准对这一块到底有什么明确的说法，就随手翻开了[C++03]，结果发现原来情况并非像很多人，乃至我所长期以来认为的那样，简而言之，有下面几个令人意外的结果，不但令我意外，当我把问题发到comp.std.c++新闻组上之后居然引起了一场不大不小的争吵，Andrew Koenig、Herb Sutter、David Abrahams、P.J Plauger...，于是我就看了几天的连台好戏，同时也把这个问题的答案在脑子里刷新了一次。
下面就是两个令人感到意外的现象：
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之间某些情况下存在着不易察觉的隐晦差别。
多的就不说了，带着上面的看法，你可以去看看我发在comp.std.c++上的帖子，地址如下：
标题：Is this really unspecified behavior?
