Entry tags:
программистское, замыкания
(эта запись может быть интересна только программистам)
Оказывается, в gcc уже черт знает сколько лет существуют замыкания в виде вложенных функций. Настоящие замыкания! Но только в C, в C++ они не работают (в C++ теперь есть лямбды, но это ж недавно).
А мужики-то и не знали! Если серьезно, я поражен.
Update. Карнавал отменяется. Это не настоящие замыкания, они не сохраняют жизнь пойманным локальным переменным при выходе из функции. Ну, так неинтересно. Как-то даже обидно стало. Пустышка.
Ладно, будем лямбды значит внедрять в народное хозяйство. Кстати, пару недель назад впервые написал настоящую лямбду в рабочем коде на C++.
Оказывается, в gcc уже черт знает сколько лет существуют замыкания в виде вложенных функций. Настоящие замыкания! Но только в C, в C++ они не работают (в C++ теперь есть лямбды, но это ж недавно).
А мужики-то и не знали! Если серьезно, я поражен.
Update. Карнавал отменяется. Это не настоящие замыкания, они не сохраняют жизнь пойманным локальным переменным при выходе из функции. Ну, так неинтересно. Как-то даже обидно стало. Пустышка.
Ладно, будем лямбды значит внедрять в народное хозяйство. Кстати, пару недель назад впервые написал настоящую лямбду в рабочем коде на C++.
no subject
no subject
P.S. Я написал пустое утверждение. Ничем не стоит злоупотреблять. Попытка придать ему значение: мне кажется, что не стоит создавать API, при использовании которых всегда напрашивается использование лямбд. Скажем, если я вызываю foo() и передаю ей callback, при вызове которого, чтобы сделать осмысленную работу, мне наверняка понадобятся локальные переменные, с помощью которых я соорудил вызов foo().
no subject
no subject
(Anonymous) 2016-05-01 01:42 am (UTC)(link)no subject
no subject
no subject
no subject
no subject
Так ведь struct _ { static int sum (.... все время работает
no subject
no subject
Более серьезная имплементация делала бы одно из двух:
- копировала переменные, использованные во вложенной функции, для ее использования (так в лямбдах C++11)
- создавала именно эти переменные не на стэке, а в куче, и давала им жить после выхода из функции (это формально говоря не нарушает стандарт, я думаю, но реально слишком сильно нарушает сложившиеся конвенции, чтобы всерьез рассматривать эту возможность)
no subject
Потому что замыкание, поинтер на который вы должны везде за собой таскать, ничем от обычного объекта не отличается.
no subject
no subject
no subject
Лямбды -- упрощенный синтаксис для создания анонимных функторов. Не стоит создавать API, принимающие функторы? А что вместо них? Сишные коллбэки в виде указателей на функцию и передачей замыканий через дополнительные аргументы? Это удобно только для интерфейса с ассемблером и си, имеет смысл в драйверах и т.п. В общем программировании удобнее принимать аргументом любой callable object, будь то функтор, лямбда, результат std::bind или std::function.
Или имеется в виду -- не надо заставлять захватывать переменные без нужды? Это да, конечно. При полном отсутствии захвата переменных легко использовать указатели на функцию, а функторы и лямбды становятся значительно более эффективными -- ведь захват -- это вызов конструктора.
Я бы сказал, что появление лямбд увеличивает полезность кода, написанного с использованием callable objects. До C++11 всяческие for_each, find_if и т.п. использовались крайне редко, потому что тривиальный цикл написать проще, чем тривиальный функтор. Функторы писали только для особо сложных или особо частых использований, и то обычно лень было. Лямбды просты, и этим стали пользоваться.
no subject
no subject
no subject
Вот тут подробно написано: http://www.airs.com/blog/archives/518