Здравствуйте, Sinclair, Вы писали:

_>>Нет, здесь не о том речь. Я здесь говорю про разницу между таким кодом:
_>>

_>>for(auto c: col) f(c);
_>>for(auto c: col) g(c);
_>>

_>>и таким кодом:
_>>

_>>for(auto c: col){
_>>    f(c);
_>>    g(c);
_>>}
_>>

_>>Надеюсь не надо объяснять разницу?)
S>Надо объяснять, откуда вообще взялся код
S>

S>  for(auto c: col) f(c);
S>  for(auto c: col) g(c);
S>

S>Никакая из предложенных реализаций в стиле linq ничего подобного не порождает.

Ну как же. Напомню, что в той нашей задачке происходила фильтрация по условию количества элементов внутренней коллекции в предыдущем элементе (который ты перевёл в текущий с помощью копирования). Т.е. при таком подходе у тебя на верхнем уровне получается не пара значений, а пара коллекций, которые ты соответственно обрабатываешь циклами.

_>>Переменная, используемая для агрегации по коллекции, в случае правильного императивного кода превращается в регистр процессора (соседствует с переменной, по которой идёт итерация цикла).
S>Ну и что? Мы же знаем, что на самом деле этих регистров процессора — много, и реальный компилятор разворачивает циклы для того, чтобы исполнитель использовал разные "eax" для соседних итераций.

Разница в том, что в твоём коде аналогичная переменная не будет регистром.