i++与++i【续】

notbusy

干了些年C以后，开始觉得这样的traps and pitfalls是用来回避的，而不是用来研讨的。

升腾

原帖由 langue 于 2010-1-8 22:07 发表
Order of evaluation of subexpressions

Many programming languages do not specify the order of evaluation of the sub-expressions of a complete expression. If one or more of the sub-expressions h ...

有点理解，就是说java是确定好了的，C/C++是未定的是吧？

升腾

原帖由 群雄逐鹿中原 于 2010-1-8 23:40 发表


其實俺是覺得, 面試題對的錯的都能出, 這個不是高考.
面试者对于错题的态度的应对策率, 应该能反映出他以后碰到bug时的态度, 是提出来解决掉?还是避过?还是掩盖?还是自我怀疑?

说实话，我希望能十分明确的回答某个问题，不十分肯定的，都不敢乱乎，自己没学好，有点心虚啊！

langue

原帖由 pmerofc 于 2010-1-10 07:50 发表

我也感觉那个帖子锁的莫名其妙
实际上undefined 和 unspecified 之间的关系对多数人来说确实是不那么清楚的
在我看来值得好好讨论一下

对于早已讨论得很清楚并且已经定性的 tips，应该是去搜索到前人讨论的内容，分析、理解前人讨论的结果，而不是月复一月一遍又一遍重复着毫无效率也毫无意义的“讨论”，这很浪费时间。

http://www.devx.com/tips/Tip/12684
http://en.wikipedia.org/wiki/Undefined_behavior
http://en.wikipedia.org/wiki/Unspecified_behavior

这也是我锁帖的原因，敬请理解。

langue

不敢。
您说的“i++ + i++ is undefined”，我在 ISO/IEC 9899:1999 里并未找到。

这里有一份资料，您可以引用，并说明是其中哪一节、哪一页的内容。
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf

langue

原帖由 notbusy 于 2010-1-9 00:32 发表
干了些年C以后，开始觉得这样的traps and pitfalls是用来回避的，而不是用来研讨的。

的确。

The moral is that writing code that depends on order of evaluation is a bad programming practice in any language. Naturally, it is necessary to know what things to avoid, but if you don't know how they are done on various machines, you won't be tempted to take advantage of a particular implementation. -- The C Programming Language, 2nd ed, Sec. 2.12, p. 54

http://www.codeguru.cn/CPP/TheCprogrammingLanguage/chapter2.html

, and

... if you don't know how they are done on various machines, that innocence may help to protect you. (1st ed)

[ 本帖最后由 langue 于 2010-1-10 15:16 编辑 ]