Foreach和For循环,用哪个?
看了一张帖子《看似简单 解读C 程序员最易犯 7大错误》,我对内容还是很支持的。
HTML code
原帖:看似简单 解读C 程序员最易犯 7大错误
作者:HooverHuang(蜗牛)
http://topic.csdn.net/u/20101110/14/a9c32275-5da2-4230-93eb-83a37285496d.html
其中讨论了for和foreach,说的是foreach的效率不及for。
但是后来我发现楼主的测试代码写错了。
测试foreach的时候没有重新计时,
导致foreach的时间变成了2次时间的累加,
出现了2倍的效率问题,实际上foreach和for循环的效率没有明显差距。
鉴于当前相当无聊,召集大伙儿闲谈讨论一下。
俺个人观点是:遍历尽量用foreach。
理由是,foreach能够更佳优雅的表达coder的用意。
C# code
for(var i=0;i<items.Count;i++){
var item=items[i];
//操作
}
for使用大篇幅的底层运算描述,从而掩盖了coder的本质用意。
相比之下foreach可读性要强的多。
而且我认为,可读性强不止对人类有效果,
对未来的计算机来说,也可能会有帮助。
如果,使用for,面对里面的那些i=0;i++,机子只能乖乖的一步一步的执行。
而如果是foreach,放手留给机子自己优化的空间,
如果未来机子足够聪明,他有机会大展伸手,
使用多核处理,使用云计算。。。(我是不是想多了) - -b
散分。
《Csdn收音机》是个开源的辅助工具,以后学技术更方便了!
------解决方案--------------------foreach效率比for低主要分2个角度说。
2个地方,一个是.net 1.1之前的对值类型的装箱,一个是每次调用GetEnumator方法的函数调用带来的时间消耗,单一次都不消耗时间,但经过大量循环放大后,时间消耗比较明显。
.net 1.1之后的版本,foreach对值类型已经不装箱,不慢了,因为有了yield关键字。
但函数调用带来的堆栈创建内存分配则不可避免。
绝对意义上,for比foreach快,但从.net 1.1之后,这个差距缩小到多一层函数调用而已,不是特别严格的地方,还是用foreach好一点。因为foreach不止可以访问一个数组或List这样循环时能确定长度的集合,也可以访问可迭代的类型,对于一些不需要最开始就确定长度的,这样甚至效率更高,因为不需要在循环开始之前就准备好要循环的数据,而是每次foreach循环获取下一个数据。
其实也不用记什么情况用,多写写程序,应该不难区分用途。
------解决方案--------------------单纯从效率上讲区别远小于对程序产生的影响
------解决方案--------------------
------解决方案--------------------这个楼主有时间可以拿个大量数据测试下,就几个数据还是看不出来的啊!测试完了发表篇博客出来瞅瞅。
给力
------解决方案--------------------对于小数据量的话,两者确实没什么区别,而对于大数据量的话建议使用For,原因2楼说得很清楚了
------解决方案--------------------能用foreach一般就懒得写for了,特别是封装的对象时,方便好多,用[]多了伤神..
至于效率也看过类似的博文,那种百万级甚至千万级执行效率的差别基本可以忽略吧
------解决方案--------------------学习了。。。。
------解决方案--------------------我个人感觉差不多,现在没时间 明天回头看看
------解决方案--------------------习惯用for
------解决方案--------------------大家可以参考下面的三篇文章:
http://blogs.msdn.com/kevin_ransom/archive/2004/04/19/116072.aspx
http://blogs.msdn.com/brada/archive/2004/04/29/123105.aspx
http://www.cnblogs.com/WuCountry/archive/2007/02/27/658710.html
------解决方案--------------------C# code
for (int count = 0; count < dt.Rows.Count; count++)
{
dt.Rows[count]["Name"] = "Modified in For";
}
------解决方案--------------------
高手论道,学习了
------解决方案--------------------
还真的没研究过他们具体的区别,只是在适当时候感觉哪个更适合自己的代码逻辑就用哪个。
今天学习了,
------解决方案--------------------
关注
------解决方案--------------------
其实用那个就看实际需要了。
一般情况都不用太较真了
------解决方案--------------------
for找到你用的东西以后就可以break了
效率高些
------解决方案--------------------