43 个解决方案
#1
对内置类型的int ,long等来说i++,++i已经不存在什么效率上有很大的差距了。对自定义类型来说一般推荐用++i，效率要高。
#2
for (int i = 0; i < 5; ++i)
i++:需要把值赋给临时变量
++i则不必了，可以省空间
i++:需要把值赋给临时变量
++i则不必了，可以省空间
#3
这个问题无所谓，效率和安全性都没什么区别。
C++primer里有大量这种改弦更张自立门户的做法，愿意听就听，不愿意听坚持C风格也没错。
C++primer里有大量这种改弦更张自立门户的做法，愿意听就听，不愿意听坚持C风格也没错。
#4
其实这些都是写小地方的问题，并没有硬性要求一定要哪种风格，毕竟两种的计算方式不同，可以在不同的地方被使用。感觉去讨论它们效率的差别意义不大
#5
后加加会产生临时变量，而前加加不会～
很多人不在乎这一点点损耗～
个人认为++i是个好习惯
很多人不在乎这一点点损耗～
个人认为++i是个好习惯
#6
现代化的编译器如果连这个差距都抹不平，微软和GNU干脆都去撞墙吧
#7
看个人习惯，我喜欢！= 和++i
#8
说的没错，但是一个优秀的程序员不应该过于依赖编译器，它只是个工具，它也有出问题的时候，什么是好习惯呢？
#9
程序员应该去关注编译器做不了的事情，比如算法优化比如代码安全（C#、JAVA连代码安全都做了，你不能说C#和java程序员不手动释放内存是没有环保意识吧……），这种细节上的优化属于过度优化。
我一直强调学习语言工具及其重要，不了解编译器的话很容易陷入这种细微风格上无谓的嘴仗……结果测试出来没区别。
#10
听高人解释。
#11
我强调的是习惯，许多大师级人物推荐你这么用自然有他的道理，一个好的习惯和细节对初级程序员是很重要的！很多公司就看中你这一点
～有一个我去一家公司面试上机，我只做了一个动作一点code没写，面试官就说我通过了：我输入了一个uname -a (linux下查询系统配置的命令)，这件事情一直在提醒我～ 细节和好的习惯是很 重要的！
#12
此习惯非彼习惯，注意缓冲区溢出、防止野指针陷阱等习惯，和++i、i++的写法，都是习惯，但是前者要比后者得分高得多，面试官让你写循环，决不会关注你用的是++i还是i++。
还有人说什么TC下单行循环不加括号比加括号快，所以不加括号是“好习惯”，暂且不论TC编译器是不是这么SB，但我个人认为这和讨论++i和i++谁好一样，意义并不大，也许早期的编译器有差别，但VC/GCC决不会有差别。
#13
我觉得应该是一个不等于比较要比一个小于比较效率高一些吧。
另外这个是跟c++迭代器有关，所以才说是c++风格。迭代器都是用不等于来比较的。
个人理解。
#14
个人觉得得看硬件条件，在底层有加法器，比较器，但是一般！=应该是指>或者<所以推荐直接用<.只是跟人感觉，并不一定正确， 呵呵 。。。
#15
细节决定成败
#16
纯学习~
#17
又回到说编译器的问题了。。。你要知道，编译器完全没有义务为我们作这个优化，VC/GCC做的确实智能，
编译器帮你优化了，你得说声谢谢，但如果有一天给你一个你不了解的编译器呢？给C++初学者的50个忠告
你总看过吧？
#18
就“大师”来说，个人觉得，C++标准委员会的大师们太想自立门户，太想改变C程序员的“思想”，太想C++一统天下，结果似乎是适得其反……
其实，如果C++标准委员会不那么标新立异，也别把C++搞那么复杂，专注于C with Class，C++搞不好已经一统天下了，实例请关注Windows下C++的地位，微软似乎就很提倡C with Class，Windows核心编程尽是这种东西，MFC是C With Class的典型，高级特征用的多的WTL官方却不支持
C with Class不善于做大规模设计么？非也，你别什么一个工程几十上百万行，动态库分清楚点，模块化搞得好一些，各个可执行文件都不会很大，都不需要复杂的面向对象设计，用C With Class甚至纯C组成一套复杂系统不是什么难事，最重要的是， C With Class效率与纯C无二
其实，如果C++标准委员会不那么标新立异，也别把C++搞那么复杂，专注于C with Class，C++搞不好已经一统天下了，实例请关注Windows下C++的地位，微软似乎就很提倡C with Class，Windows核心编程尽是这种东西，MFC是C With Class的典型，高级特征用的多的WTL官方却不支持
C with Class不善于做大规模设计么？非也，你别什么一个工程几十上百万行，动态库分清楚点，模块化搞得好一些，各个可执行文件都不会很大，都不需要复杂的面向对象设计，用C With Class甚至纯C组成一套复杂系统不是什么难事，最重要的是， C With Class效率与纯C无二
#19
这一般不需要细求吧，除了一些特别的场合
#20
要不要我逐一反驳那50条？如果真按照那个来，就误入歧途了，典型的学院派。
谁说编译器没有义务，没有义务的话为什么任何编译器都做优化？
你可能搞错编译器“中立”的概念了，我们不应该写那种未定义行为比如fflush(stdin)，比如i+++i+++i，但是基本的优化是所有编译器都做的，更何况即便编译器不做也不会产生严重问题，效率稍低而已。
#21
可以关注我以前的帖子，那种什么“学C不要关注工具”，“学C不要关注操作系统”，“学C应该集中注意力于语言本身”，“初学不能用太复杂的IDE”……都是我一直反对的。
学C就要用好工具，TC学不好C；
学C就要关注操作系统，没有Windows API和linux 系统调用，单凭标准库，除了上课学语法学算法，屁事做不了。
初学一定要用VC或GCC，这才是生产实践中用的，gcc可以不用IDE，但也要熟悉vim、gdb等一大票工具的用法，光知道gcc xxx.c不可能学好C，因此想学好C就不可能只关注语言本身。
学C就要用好工具，TC学不好C；
学C就要关注操作系统，没有Windows API和linux 系统调用，单凭标准库，除了上课学语法学算法，屁事做不了。
初学一定要用VC或GCC，这才是生产实践中用的，gcc可以不用IDE，但也要熟悉vim、gdb等一大票工具的用法，光知道gcc xxx.c不可能学好C，因此想学好C就不可能只关注语言本身。
#22
那你告诉我～都有哪些编译器为我们作了++i和i++的优化呢？你又知道哪些编译器呢？
我说编译器没有义务为我们作++i和i++的优化错了吗？难道说没有作这种优化就不叫编译器了吗？
你说编译器是中立的又能说明什么呢？
你一直在强调编译器帮我们做什么什么～ 那有一天编译器能帮我们写code了，那你就失业了？
你说～即使编译器不作优化也不会错～只会低效率～ 那还吵什么呢？这正是我的观点阿
#23
请这为对c++标委会有意见的大牛人物～ 依依回答我的问题
#24
我想你平时写软件时，不到交付的时候绝不会加优化选项（你是linux编程的？是不是平时-o2、-o3从没用过），这很危险，因为加不加优化程序的表现很可能不同。
至于你的问题，按照顺序
1.如果你是用的是VC和GCC之外的编译器（优化做得最好），除非你是特殊的平台（比如AIX或Solaris），为你的前途考虑，请换回主流。
2.同上，你愿意用什么CC386、pacific C、lcc、pelles C、sdcc、tcc、bdsc……啥的，却是我不能否认这些也是C编译器，但是换掉为妙。
3.如果不理解我说的未定义行为，请再看一遍C++ primer等基础教材
4.如果哪天计算机能够直接听懂英语或中国话，程序员确实是失业了，这没什么好质疑的，就是这样，很残酷
5.同1，2，如果，GCC和VC的编译结果比非主流编译器快，请不要坚持非主流
#25
看C++primer 后，现在也习惯写成++i 了，呵呵
#26
理论上来说，是有差别的，
根据操作符重载原理，++i返回自身引用，而i++会产生临时变量，
但是，这些差别不是我们最关注的
到底使用i++还是++i，更要看需要来定，而不是看效率来定，
还有i < n ,还是i != n
完全习惯问题了
哪个容易理解，哪个更不容易出错，就用哪个
根据操作符重载原理，++i返回自身引用，而i++会产生临时变量，
但是，这些差别不是我们最关注的
到底使用i++还是++i，更要看需要来定，而不是看效率来定，
还有i < n ,还是i != n
完全习惯问题了
哪个容易理解，哪个更不容易出错，就用哪个
#27
没看出啥差别
#28
项目从Debug版本到release版本必须要优化哦～
-o3优化后肯定会大幅压缩的一般是1/10不到，你说会危险？那就乱说了不是～
对于一个老程序员来说 想改变某种习惯确实是一件很难的实情了，甚至他可能一辈子都认为自己的习惯是对的（甚至有的人不知道习惯是个什么概念），可对于初学者而言（包括我）,习惯确实很重要～ 我还会坚持c++ primer 里面的 for(size_t i=0;i<n;++i){}
#29
争论这些不影响效率的细节问题真的没有意义，程序员该关注的不是++i或者是i++的问题，或者一个隐含的inline函数是否该声明为inline?编译器能搞定的事就留给编译器，不是不知道++i与i++的区别，编译器优化之后没有区别，犯不着为这个争论吧。
#30
还没考虑到这一步。。。
#31
一般的小规模程序优化没什么问题，大规模的话尤其是本身里面有些bug，优化后的结果却是可能不同
#32
对于一个问题要知其然也得知其所以然，最终的结论和做法可能倒无所谓，关键看你怎么想的，记得在公司里我就看到有的.net程序员把if(i==1)这类的代码改成if(1==i)，如果是从做C，C++的老程序员顺其自然保留下来的习惯是值得赞赏的，但如果是仅从刻意模仿这种形式风格，而不去钻研其中原因，把精力都放在这些小细节上，特别是由于较早的编译器的不强大而产生的很多看似奇怪的编码习惯上，就没有什么必要了。当然如果说你精力超级充沛，大脑超级聪明，在充分考虑到代码的逻辑、系统的设计这些问题外还是可以关注下的，不过我们毕竟精力有限哈，所以得把心思放在主要的事情上面
#33
楼主
就当没区别
就当没区别
#34
纯学习来的!
#35
学习了......
#36
-o3会不会有bug就要关注GNU相关网站了，因为开源一般都很诚实的，不能靠自己估计或道听途说
难道你真的这么幸运？碰到了-o3的BUG?
#37
回复很精彩
#38
“<”需要重载“<”
“!=”需要重载“==”
#39
我遇见的不是o3的bug，而是程序中的bug在debug和release中不一致，也许debug跑通的release就出错，这不是编译器的责任，错在程序员
至于优化本身的bug，我VC用得多，还真见过，VS2005的指针数组优化确实有bug
#40
举个最简单的例子吧
char str[16];
//然后给str赋一段值（小于16），用aes加密算法加密
VC分别用debug和release是什么结果。
用debug，可以保证每次加密结果一样，验证成功
release则不一定。
为什么？因为debug会初始化内存为0xcc，release不会因此内存随机，如果16个字节没有填满，而aes算法又是16字节的分组，就会造成release版本下加密随机数，结果当然不一样。
这就是程序中的bug，正确做法是char str[16] = {0};初始化，如果只用debug模式编译，就无法发现这个bug。
char str[16];
//然后给str赋一段值（小于16），用aes加密算法加密
VC分别用debug和release是什么结果。
用debug，可以保证每次加密结果一样，验证成功
release则不一定。
为什么？因为debug会初始化内存为0xcc，release不会因此内存随机，如果16个字节没有填满，而aes算法又是16字节的分组，就会造成release版本下加密随机数，结果当然不一样。
这就是程序中的bug，正确做法是char str[16] = {0};初始化，如果只用debug模式编译，就无法发现这个bug。
#41
++i确实快一点点
但那种快你循环1亿次也感觉不到
但那种快你循环1亿次也感觉不到
#42
可算看完了...都快打起来了....楼上的大牛们其实无解我的意思了...我明白自己的精力应该放在更有意义的地方，而不是这些细节上面，但是我挺注重程序风格的，感觉代码给比人看，人家代码风格是第一印象，我想得到的答案其实已经有人说了：也许和地带器有关，c++里面有迭代器，用！=就能统一了，嘿嘿，结贴了，感谢大牛们的帮忙
#43
看了各位大牛的争论，确实受益匪浅
作为一个初学者，我想说，看到这篇帖子，这些争论是一种幸运，否则我一辈子都在用i++，估计要很久才知道i++有临时变量产生
在这里，谢谢大家了
在这里，我也想发表下自己的看法
我觉得，很多时候，这两种通用，所以，用哪种都无所谓的。
只有在语言区分它们的时候可以明确就好了
如果编程光扣这种细小的地方，那岂不是要累死？
有些时候要考虑宏观，有些时候要考虑微观，没有定死的说法
作为一个初学者，我想说，看到这篇帖子，这些争论是一种幸运，否则我一辈子都在用i++，估计要很久才知道i++有临时变量产生
在这里，谢谢大家了
在这里，我也想发表下自己的看法
我觉得，很多时候，这两种通用，所以，用哪种都无所谓的。
只有在语言区分它们的时候可以明确就好了
如果编程光扣这种细小的地方，那岂不是要累死？
有些时候要考虑宏观，有些时候要考虑微观，没有定死的说法
#1
对内置类型的int ,long等来说i++,++i已经不存在什么效率上有很大的差距了。对自定义类型来说一般推荐用++i，效率要高。
#2
for (int i = 0; i < 5; ++i)
i++:需要把值赋给临时变量
++i则不必了，可以省空间
i++:需要把值赋给临时变量
++i则不必了，可以省空间
#3
这个问题无所谓，效率和安全性都没什么区别。
C++primer里有大量这种改弦更张自立门户的做法，愿意听就听，不愿意听坚持C风格也没错。
C++primer里有大量这种改弦更张自立门户的做法，愿意听就听，不愿意听坚持C风格也没错。
#4
其实这些都是写小地方的问题，并没有硬性要求一定要哪种风格，毕竟两种的计算方式不同，可以在不同的地方被使用。感觉去讨论它们效率的差别意义不大
#5
后加加会产生临时变量，而前加加不会～
很多人不在乎这一点点损耗～
个人认为++i是个好习惯
很多人不在乎这一点点损耗～
个人认为++i是个好习惯
#6
现代化的编译器如果连这个差距都抹不平，微软和GNU干脆都去撞墙吧
#7
看个人习惯，我喜欢！= 和++i
#8
说的没错，但是一个优秀的程序员不应该过于依赖编译器，它只是个工具，它也有出问题的时候，什么是好习惯呢？
#9
程序员应该去关注编译器做不了的事情，比如算法优化比如代码安全（C#、JAVA连代码安全都做了，你不能说C#和java程序员不手动释放内存是没有环保意识吧……），这种细节上的优化属于过度优化。
我一直强调学习语言工具及其重要，不了解编译器的话很容易陷入这种细微风格上无谓的嘴仗……结果测试出来没区别。
#10
听高人解释。
#11
我强调的是习惯，许多大师级人物推荐你这么用自然有他的道理，一个好的习惯和细节对初级程序员是很重要的！很多公司就看中你这一点
～有一个我去一家公司面试上机，我只做了一个动作一点code没写，面试官就说我通过了：我输入了一个uname -a (linux下查询系统配置的命令)，这件事情一直在提醒我～ 细节和好的习惯是很 重要的！
#12
此习惯非彼习惯，注意缓冲区溢出、防止野指针陷阱等习惯，和++i、i++的写法，都是习惯，但是前者要比后者得分高得多，面试官让你写循环，决不会关注你用的是++i还是i++。
还有人说什么TC下单行循环不加括号比加括号快，所以不加括号是“好习惯”，暂且不论TC编译器是不是这么SB，但我个人认为这和讨论++i和i++谁好一样，意义并不大，也许早期的编译器有差别，但VC/GCC决不会有差别。
#13
我觉得应该是一个不等于比较要比一个小于比较效率高一些吧。
另外这个是跟c++迭代器有关，所以才说是c++风格。迭代器都是用不等于来比较的。
个人理解。
#14
个人觉得得看硬件条件，在底层有加法器，比较器，但是一般！=应该是指>或者<所以推荐直接用<.只是跟人感觉，并不一定正确， 呵呵 。。。
#15
细节决定成败
#16
纯学习~
#17
又回到说编译器的问题了。。。你要知道，编译器完全没有义务为我们作这个优化，VC/GCC做的确实智能，
编译器帮你优化了，你得说声谢谢，但如果有一天给你一个你不了解的编译器呢？给C++初学者的50个忠告
你总看过吧？
#18
就“大师”来说，个人觉得，C++标准委员会的大师们太想自立门户，太想改变C程序员的“思想”，太想C++一统天下，结果似乎是适得其反……
其实，如果C++标准委员会不那么标新立异，也别把C++搞那么复杂，专注于C with Class，C++搞不好已经一统天下了，实例请关注Windows下C++的地位，微软似乎就很提倡C with Class，Windows核心编程尽是这种东西，MFC是C With Class的典型，高级特征用的多的WTL官方却不支持
C with Class不善于做大规模设计么？非也，你别什么一个工程几十上百万行，动态库分清楚点，模块化搞得好一些，各个可执行文件都不会很大，都不需要复杂的面向对象设计，用C With Class甚至纯C组成一套复杂系统不是什么难事，最重要的是， C With Class效率与纯C无二
其实，如果C++标准委员会不那么标新立异，也别把C++搞那么复杂，专注于C with Class，C++搞不好已经一统天下了，实例请关注Windows下C++的地位，微软似乎就很提倡C with Class，Windows核心编程尽是这种东西，MFC是C With Class的典型，高级特征用的多的WTL官方却不支持
C with Class不善于做大规模设计么？非也，你别什么一个工程几十上百万行，动态库分清楚点，模块化搞得好一些，各个可执行文件都不会很大，都不需要复杂的面向对象设计，用C With Class甚至纯C组成一套复杂系统不是什么难事，最重要的是， C With Class效率与纯C无二
#19
这一般不需要细求吧，除了一些特别的场合
#20
要不要我逐一反驳那50条？如果真按照那个来，就误入歧途了，典型的学院派。
谁说编译器没有义务，没有义务的话为什么任何编译器都做优化？
你可能搞错编译器“中立”的概念了，我们不应该写那种未定义行为比如fflush(stdin)，比如i+++i+++i，但是基本的优化是所有编译器都做的，更何况即便编译器不做也不会产生严重问题，效率稍低而已。
#21
可以关注我以前的帖子，那种什么“学C不要关注工具”，“学C不要关注操作系统”，“学C应该集中注意力于语言本身”，“初学不能用太复杂的IDE”……都是我一直反对的。
学C就要用好工具，TC学不好C；
学C就要关注操作系统，没有Windows API和linux 系统调用，单凭标准库，除了上课学语法学算法，屁事做不了。
初学一定要用VC或GCC，这才是生产实践中用的，gcc可以不用IDE，但也要熟悉vim、gdb等一大票工具的用法，光知道gcc xxx.c不可能学好C，因此想学好C就不可能只关注语言本身。
学C就要用好工具，TC学不好C；
学C就要关注操作系统，没有Windows API和linux 系统调用，单凭标准库，除了上课学语法学算法，屁事做不了。
初学一定要用VC或GCC，这才是生产实践中用的，gcc可以不用IDE，但也要熟悉vim、gdb等一大票工具的用法，光知道gcc xxx.c不可能学好C，因此想学好C就不可能只关注语言本身。
#22
那你告诉我～都有哪些编译器为我们作了++i和i++的优化呢？你又知道哪些编译器呢？
我说编译器没有义务为我们作++i和i++的优化错了吗？难道说没有作这种优化就不叫编译器了吗？
你说编译器是中立的又能说明什么呢？
你一直在强调编译器帮我们做什么什么～ 那有一天编译器能帮我们写code了，那你就失业了？
你说～即使编译器不作优化也不会错～只会低效率～ 那还吵什么呢？这正是我的观点阿
#23
请这为对c++标委会有意见的大牛人物～ 依依回答我的问题
#24
我想你平时写软件时，不到交付的时候绝不会加优化选项（你是linux编程的？是不是平时-o2、-o3从没用过），这很危险，因为加不加优化程序的表现很可能不同。
至于你的问题，按照顺序
1.如果你是用的是VC和GCC之外的编译器（优化做得最好），除非你是特殊的平台（比如AIX或Solaris），为你的前途考虑，请换回主流。
2.同上，你愿意用什么CC386、pacific C、lcc、pelles C、sdcc、tcc、bdsc……啥的，却是我不能否认这些也是C编译器，但是换掉为妙。
3.如果不理解我说的未定义行为，请再看一遍C++ primer等基础教材
4.如果哪天计算机能够直接听懂英语或中国话，程序员确实是失业了，这没什么好质疑的，就是这样，很残酷
5.同1，2，如果，GCC和VC的编译结果比非主流编译器快，请不要坚持非主流
#25
看C++primer 后，现在也习惯写成++i 了，呵呵
#26
理论上来说，是有差别的，
根据操作符重载原理，++i返回自身引用，而i++会产生临时变量，
但是，这些差别不是我们最关注的
到底使用i++还是++i，更要看需要来定，而不是看效率来定，
还有i < n ,还是i != n
完全习惯问题了
哪个容易理解，哪个更不容易出错，就用哪个
根据操作符重载原理，++i返回自身引用，而i++会产生临时变量，
但是，这些差别不是我们最关注的
到底使用i++还是++i，更要看需要来定，而不是看效率来定，
还有i < n ,还是i != n
完全习惯问题了
哪个容易理解，哪个更不容易出错，就用哪个
#27
没看出啥差别
#28
项目从Debug版本到release版本必须要优化哦～
-o3优化后肯定会大幅压缩的一般是1/10不到，你说会危险？那就乱说了不是～
对于一个老程序员来说 想改变某种习惯确实是一件很难的实情了，甚至他可能一辈子都认为自己的习惯是对的（甚至有的人不知道习惯是个什么概念），可对于初学者而言（包括我）,习惯确实很重要～ 我还会坚持c++ primer 里面的 for(size_t i=0;i<n;++i){}
#29
争论这些不影响效率的细节问题真的没有意义，程序员该关注的不是++i或者是i++的问题，或者一个隐含的inline函数是否该声明为inline?编译器能搞定的事就留给编译器，不是不知道++i与i++的区别，编译器优化之后没有区别，犯不着为这个争论吧。
#30
还没考虑到这一步。。。
#31
一般的小规模程序优化没什么问题，大规模的话尤其是本身里面有些bug，优化后的结果却是可能不同
#32
对于一个问题要知其然也得知其所以然，最终的结论和做法可能倒无所谓，关键看你怎么想的，记得在公司里我就看到有的.net程序员把if(i==1)这类的代码改成if(1==i)，如果是从做C，C++的老程序员顺其自然保留下来的习惯是值得赞赏的，但如果是仅从刻意模仿这种形式风格，而不去钻研其中原因，把精力都放在这些小细节上，特别是由于较早的编译器的不强大而产生的很多看似奇怪的编码习惯上，就没有什么必要了。当然如果说你精力超级充沛，大脑超级聪明，在充分考虑到代码的逻辑、系统的设计这些问题外还是可以关注下的，不过我们毕竟精力有限哈，所以得把心思放在主要的事情上面
#33
楼主
就当没区别
就当没区别
#34
纯学习来的!
#35
学习了......
#36
-o3会不会有bug就要关注GNU相关网站了，因为开源一般都很诚实的，不能靠自己估计或道听途说
难道你真的这么幸运？碰到了-o3的BUG?
#37
回复很精彩
#38
“<”需要重载“<”
“!=”需要重载“==”
#39
我遇见的不是o3的bug，而是程序中的bug在debug和release中不一致，也许debug跑通的release就出错，这不是编译器的责任，错在程序员
至于优化本身的bug，我VC用得多，还真见过，VS2005的指针数组优化确实有bug
#40
举个最简单的例子吧
char str[16];
//然后给str赋一段值（小于16），用aes加密算法加密
VC分别用debug和release是什么结果。
用debug，可以保证每次加密结果一样，验证成功
release则不一定。
为什么？因为debug会初始化内存为0xcc，release不会因此内存随机，如果16个字节没有填满，而aes算法又是16字节的分组，就会造成release版本下加密随机数，结果当然不一样。
这就是程序中的bug，正确做法是char str[16] = {0};初始化，如果只用debug模式编译，就无法发现这个bug。
char str[16];
//然后给str赋一段值（小于16），用aes加密算法加密
VC分别用debug和release是什么结果。
用debug，可以保证每次加密结果一样，验证成功
release则不一定。
为什么？因为debug会初始化内存为0xcc，release不会因此内存随机，如果16个字节没有填满，而aes算法又是16字节的分组，就会造成release版本下加密随机数，结果当然不一样。
这就是程序中的bug，正确做法是char str[16] = {0};初始化，如果只用debug模式编译，就无法发现这个bug。
#41
++i确实快一点点
但那种快你循环1亿次也感觉不到
但那种快你循环1亿次也感觉不到
#42
可算看完了...都快打起来了....楼上的大牛们其实无解我的意思了...我明白自己的精力应该放在更有意义的地方，而不是这些细节上面，但是我挺注重程序风格的，感觉代码给比人看，人家代码风格是第一印象，我想得到的答案其实已经有人说了：也许和地带器有关，c++里面有迭代器，用！=就能统一了，嘿嘿，结贴了，感谢大牛们的帮忙
#43
看了各位大牛的争论，确实受益匪浅
作为一个初学者，我想说，看到这篇帖子，这些争论是一种幸运，否则我一辈子都在用i++，估计要很久才知道i++有临时变量产生
在这里，谢谢大家了
在这里，我也想发表下自己的看法
我觉得，很多时候，这两种通用，所以，用哪种都无所谓的。
只有在语言区分它们的时候可以明确就好了
如果编程光扣这种细小的地方，那岂不是要累死？
有些时候要考虑宏观，有些时候要考虑微观，没有定死的说法
作为一个初学者，我想说，看到这篇帖子，这些争论是一种幸运，否则我一辈子都在用i++，估计要很久才知道i++有临时变量产生
在这里，谢谢大家了
在这里，我也想发表下自己的看法
我觉得，很多时候，这两种通用，所以，用哪种都无所谓的。
只有在语言区分它们的时候可以明确就好了
如果编程光扣这种细小的地方，那岂不是要累死？
有些时候要考虑宏观，有些时候要考虑微观，没有定死的说法