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

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

ГВ>>>Я признаю наличие в других языках других реализаций лямбд. Но я не считаю "единственно нормальной" реализацию лямбд в каком-то определённом языке, или их наборе. Например, то, что лямбды в "других" языках непременно требуют вовлечения GC я считаю изъяном их реализации, пусть и повсеместно встречающимся. Я, например, знаю, что использование лямбда-выражений не всегда требует отдельного управления жизненным циклом замкнутых переменных. Отсюда, я не думаю, что непременное привлечение GC — "нормально", т.е., сродни эталону.
G>>А другие варианты есть? Явное управление временем жизни не подойдет, надеюсь это понятно.

ГВ>Да варианты-то самые обыкновенные: от отсутствия специального управления, до подсчёта ссылок и опционального (!) GC. Пойми, я не против GC самого по себе, я не люблю, когда мне его навязывают в обязательном порядке. Вот в маленькой локальной лямбде:

ГВ>

ГВ>int upper = ...;
ГВ>it = find_if(v.begin(), v.end(), [=](int x) -> bool { return x >= 0 && x <= upper; })
ГВ>

ГВ>на фига GC? Здесь вполне достаточно снапшота по значению. Её вообще имеет смысл всю инлайнировать (кстати, я охотно допускаю, что JIT именно так и поступит). И ещё в десятках ситуаций, когда время существования вовлечённых объектов гарантированно превышает время существования лямбды — зачем GC? Зачем GC вообще ставить в известность о том, что ты создаёшь какую-то там лямбду, когда ты на 100% уверен, что она будет удалена до того, как пропадут использованные ей объекты?

Простые случаи мало интересуют, они будут отлично оптимизироваться JIT. Наличие или остуствие GC там никакой роли не играет.
В более сложных случаях, когда требуется GC, подсчет ссылок дает оверхед, как и опциональный GC.
Не получится сделать в C++ сборщик мусора, сравнимый по быстродействию с .NETовским.

В итоге пришли к тому же: С++, даже в новом стандарте, позволяет эффективно использовать только подмножество лямбд.