> А если я в цикле присвою счетчику другое значение? for mut i in 0..10 {
println!("{}", i);
i += 1;
}
результат компиляции:
warning: value assigned to `i` is never read
--> tmp.rs:4:9
|
4 | i += 1;
| ^
|
= note: #[warn(unused_assignments)] on by default
Я поясню на всякий случай: изменение i на итерации цикла никак не влияет на то, с какими значениями i будет вызвано тело цикла.
> А если обращусь к a[i+1] на последней итерации?
И как это будет выглядеть? Может так?
for i in 0..a.len() {
if i == a.len() - 1 {
println!("{}", a[i+1]);
}
}
Или как-то интереснее? В приведённом варианте, компилятор, раскрывая a[i+1], заинлайнит метод a.index(i+1), и таким образом вставит в код проверку i+1<a.len(), а дальше llvm, найдя эту проверку, заметит, что проверка не нужна, потому что если выполняется i==a.len()-1, то i+1<a.len() гарантированно не выполняется, значит можно ругнуться о dead_code и вышвырнуть из кода println!, а затем и весь if тоже, а затем ещё и цикл, потому что это код не имеющий побочных эффектов.
Если мы просто будем обращаться к a[i+1], без всяких условий, то тут есть два варианта. Если цикл пойдёт по диапазону 0..a.len()-1, то проверка внутри цикла будет выкинута оптимизатором как ненужная. Если цикл пойдёт по большему диапазону, то проверка останется, потому что оптимизатор не сможет доказать, что она не нужная, и в этом случае мы собственно и получим панику на этапе выполнения.
А если компилятор для цикла 0..a.len() сможет вычислить точный размер a на этапе компиляции, то, я подозреваю, он сделает цикл по диапазону 0..a.len()-1, который не будет содержать проверок, а после цикла вызовет panic! (тот который должен был случится, в силу выхода индекса за границы массива). То есть там будет одна проверка на весь код, и эта проверка будет связана с организацией цикла. Если конечно компилятор не развернёт этот цикл, так чтобы он превратился бы в линейный код.
Все эти вещи компиляторы C тоже умеют делать не хуже чем компилятор rust'а, вы можете поизучать эти возможности оптимизаторов даже не связываясь с rust'ом, для этого достаточно освоить опции -S, -fverbose-asm, и ещё полезно подчастую -Os вставлять вместо -O2 -- так ассемблерный выхлоп получается понятнее человеку, правда это искажает результаты оптимизации. И я очень рекомендую поизучать их, потому что использование C без знания того, как компилятор генерит код -- это... я не знаю, как это назвать, но это совершенно неправильно. Так не выйдет писать хороший код на C, можно писать что-нибудь в стиле exim, но не хороший код.
