(更新)
实际上 - 有一种情况for
构建更高效;在数组上循环。编译器/JIT 针对这种情况进行了优化只要你使用 arr.Length
在条件下:
for(int i = 0 ; i < arr.Length ; i++) {
Console.WriteLine(arr[i]); // skips bounds check
}
在这种非常特殊的情况下,它会跳过边界检查,因为它已经知道它永远不会越界。有趣的是,如果你“举起”arr.Length
要尝试手动优化它,可以防止这种情况发生:
int len = arr.Length;
for(int i = 0 ; i < len ; i++) {
Console.WriteLine(arr[i]); // performs bounds check
}
但是,对于其他容器(List<T>
等),作为手动微优化,提升是相当合理的。
(更新结束)
两者都不;无论如何,for 循环在底层都会被评估为 while 循环。
例如,ECMA 334(明确赋值)的 12.3.3.9 规定 for 循环:
for ( for-initializer ; for-condition ; for-iterator ) embedded-statement
本质上是等价的(从明确的任务透视图(与“编译器必须生成此 IL”不太一样))为:
{
for-initializer ;
while ( for-condition ) {
embedded-statement ;
LLoop:
for-iterator ;
}
}
带有目标的 continue 语句
for 语句被翻译为
针对标签的 goto 语句
循环。如果省略 for 条件
从 for 语句中,然后
明确分配的评估
如同 for-condition 一样进行
将上面的内容替换为 true
扩张。
现在,这并不意味着编译器必须做完全相同的事情,但实际上它几乎是这样做的......