Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
Я только начал вникать в С++0x, но уже сожалею, что убрали концепты. Спасибо за разъяснение. Надеюсь на продолжение.
Спасибо Вам за оценку. Следующей статьёй я думал написать о ссылках на rvalue (rvalue references) также из будущего стандарта.
Да, да, обязательно пишите — у вас это прекрасно получается. Я хоть и почитал уже довольно много про это, но лишним такое описание, как тут, не будет. Ждём!
Обязательно пишите, статья получилась очень хорошая и толковая (и потом — желания курить новый стандарт я в себе так и не нашел, а тут все понятно и доступно).
Пишите пожалуйста. Из нового стандарта rvalue refs — это самое мутное для меня, пожалуй. С удовольствием прочитаю.
Для простоты можете представить, что это «ссылка на ссылку» (по аналогии «указатель на указатель»).
Мне вот интересно, что GooRooнапишет, покольку я себе примерно представляю для чего это нужно, но он может что-то такое рассказать, что позволит эту фичу использовать ещё эффективней в будущем как говорится — «век живи — век учись» :)
Мне вот интересно, что GooRooнапишет, покольку я себе примерно представляю для чего это нужно, но он может что-то такое рассказать, что позволит эту фичу использовать ещё эффективней в будущем как говорится — «век живи — век учись» :)
Слушай, чувак, респект и уважуха за столь подробное разжёвывание темы лямбда-выражений в С++. Очень порадовало, что ты не только рассказал всё более подробно, но и рассказал про подоснову всей этой кухни (это я про функторы). Теперь эти лямбда-выражения в C++ меня реально заинтересовали :) Обязательно теперь поэкспериментирую надосуге…
В последнее время наращивание вычислительной мощности процессоров замедлило ход, и развитие компьютерной техники пошло по пути распараллеливания вычислений. Поэтому в моду начнут входить чистые функциональные языки программирования, такие как Haskell к примеру, ибо в них это самое распараллеливание делается крайне легко. Но так как на текущий момент одним из нюансов является не слишком высокое быстродействие программ, написанных на Haskell, в сравнении с их C++-аналогами, скорее всего в будущем появится новая, гибридная методология, которая будет включать как элементы ООП и функционального программирования, так и, возможно, что-то совершенно новое. IMHO :)
Каким образом (анонимные) функторы противоречат ООП?
Это не goto, это способ алгоритмической абстракции (здесь в статье хороших примеров нету, но подошло бы объяснение fold/map).
В ООП (которое message passing) такие «костыли» (лол) тоже есть, ибо сами сообщения — объекты первого класса.
Как раз таки *отсутствие* функций/сообщений первого класса приводит к костылям.
В ООП (которое message passing) такие «костыли» (лол) тоже есть, ибо сами сообщения — объекты первого класса.
Как раз таки *отсутствие* функций/сообщений первого класса приводит к костылям.
А то, что само ООП в С++ немного костыльное, вас не смущает?
да у меня то же что-то ругается на этом месте
$ gcc-config -c
x86_64-pc-linux-gnu-4.4.1
получается в последнем gcc эта фича еще не реализована, очень жаль.
P.S. Хотя, с другой стороный, второй листинг скомпилировался без поблем.
x86_64-pc-linux-gnu-4.4.1
получается в последнем gcc эта фича еще не реализована, очень жаль.
P.S. Хотя, с другой стороный, второй листинг скомпилировался без поблем.
извиняюсь, туплю ) там же нет никаких лямбд.
А так спасибо, очень интересно, в общем-то как и все новое (:
А так спасибо, очень интересно, в общем-то как и все новое (:
Статья действительно хорошая. А вот лямбды в c++ конечно выглядят громоздко. По той же причине, я использую замыкания в javascript но не использую анонимных функций т.к. это выглядит не так мило как в Lisp/Haskell/ML и проще объявить их рядышком.
суровая статья, спасибо
у меня вопрос: как все это будет работать без автоматической сборки мусора? я псал на С++ достаточно давно и уже не в теме, но не принесут ли лямбды в С++ лишней головной боли с утечками памяти? и вообще они каким-то образом влияют в этом вопросе или бояться нечего? мне было бы интересно узнать
за статью спасибо, жду продолжений и подобных статей, автор, пиши еще :-)
у меня вопрос: как все это будет работать без автоматической сборки мусора? я псал на С++ достаточно давно и уже не в теме, но не принесут ли лямбды в С++ лишней головной боли с утечками памяти? и вообще они каким-то образом влияют в этом вопросе или бояться нечего? мне было бы интересно узнать
за статью спасибо, жду продолжений и подобных статей, автор, пиши еще :-)
std::copy( a.begin(), a.end(), std::ostream_iterator( std::cout, " " ) );
а не надуманные трейслямбды
а не надуманные трейслямбды
и опять ни слова про действие лямбды вне области видимости переменных.
Там есть и такое. Трейслямбда чисто для примера. Давайте тогда так:
int elementsInRow = 0;
auto traceLambda = [=] (int _val) mutable
{
cout << _val << " ";
if (++elementsInRow % 5 == 0)
{
elementsInRow = 0;
cout << endl;
}
};
А зачем elementsInRow обнулять если % 5 написано? Можно либо написать if (++elementsInRow == 5) либо убрать обнуление, без изменения смысла
Громоздко слишком. Вот в том же ATS (ats-lang.org) это делается проще и практически также эффективно.
Да-да, я понимаю, что это исследовательский язык и все такое, но С++никам следует обратить на него пристальное внимание.
Да-да, я понимаю, что это исследовательский язык и все такое, но С++никам следует обратить на него пристальное внимание.
Скорее всего, это просто тренды, не следовать которым — отставать в практической применимости. С++ изначально представлялся конструктором, с помощью которого можно стоить не только дома, но и инструмент, с помощью которого эти дома делаются. Но когда количество самодельного инструмента превысило отметку в 9000, все-таки решили причесать этот зоопарк и ввести наиболее употребимое непосредственно в язык. Временами получается несколько неуклюже (как раз из-за начальной ориентации в перпендикулярном направлении): и синтаксис лямб — не верх изящества.
Только монад и pattern matching'а не хватает)
В листинге 13 необходимо явно указывать возвращаемый тип первой лямбды
-> void?
Есть неосвещённое белое пятно.
Что происходит со ссылками на переменные, вышедшие из области видимости?
function<void ()> foo()
{
int init = 0;
return [&init]() { ++init; };
}
Подозреваю, что со ссылкой ничего не произойдёт, после возврата из foo она будет указывать на адрес на стеке и использование результата функции foo() будет разрушать значение в этой ячейке стека.
Или я не прав?
Что происходит со ссылками на переменные, вышедшие из области видимости?
function<void ()> foo()
{
int init = 0;
return [&init]() { ++init; };
}
Подозреваю, что со ссылкой ничего не произойдёт, после возврата из foo она будет указывать на адрес на стеке и использование результата функции foo() будет разрушать значение в этой ячейке стека.
Или я не прав?
> Есть неосвещённое белое пятно.
Мда, ну и фразу написал…
Grammar nazi негодуе.
Мда, ну и фразу написал…
Grammar nazi негодуе.
Замените это на функторы и всё станет ясно.
Вы сохранили ссылку на переменную, которой после выхода из функции нет. Что в таком случае положено? Не важно, лямбда там или нет, обращение по этой ссылке — undefined behaviour.
Вы сохранили ссылку на переменную, которой после выхода из функции нет. Что в таком случае положено? Не важно, лямбда там или нет, обращение по этой ссылке — undefined behaviour.
Прекрасная статья, снимаю шляпу вместе с волосами перед умением автора доносить мыслю. Отплюсовался где только мог :)
спасибо за статью. тема сисек лямбда функций почти раскрыта
респект автору. статья очень полезная.
Спасибо, было приятно ознакомиться, пока еще не приходилось читать такого внятного рассказа о лямбдах в C++.
Спасибо большое за ссылку! Почитал. Довольно интересно, но я так и не заставил себя всерьез заняться изучением Objective-C. На первый взгляд замыкания там действительно попроще, чем в C++ :)
Если нужно компилировать только средствами от Apple, то это уже не чистые C/C++ ;)
P.S. Ей-богу, не осилил разобраться в XCode. Мне сказали, что XCode удобно использовать только для Obj-C, но не для C++. Посему с программингом под Mac у меня как-то вообще не сложилось.
P.S. Ей-богу, не осилил разобраться в XCode. Мне сказали, что XCode удобно использовать только для Obj-C, но не для C++. Посему с программингом под Mac у меня как-то вообще не сложилось.
а нетипизированные лямбда-функции существуют (в виде шаблонов)?
А зачем?
я же вас не спрашиваю, зачем ввели лямбду, когда спокойно обходилось обычными функторами. вот и вы, пожалуйста, тоже…
ладно, так уж и быть, отвечу на ваш вопрос. без лямбда-шаблонов новшество будет уступать функторам в гибкости.
ладно, так уж и быть, отвечу на ваш вопрос. без лямбда-шаблонов новшество будет уступать функторам в гибкости.
Если ввели, значит «обходились неспокойно», однако для программистов С++ (не знакомых с функциональным программированием) лямбда-выражения скорее всего будут не более чем синтаксическим сахаром, который иногда весьма удобно использовать. Но Вам же никто не говорит заменять все функторы на лямбды.
А как Вы себе вообще представляете объявление шаблонной лямбды?
А как Вы себе вообще представляете объявление шаблонной лямбды?
А так ли важно, как я их себе представляю? То, что паре программистов с хабра не удалось этот синтаксис себе вообразить, не должно наводить на мысль о невозможности или ненужности. Было бы желание, а синтаксис придумать можно. Да хоть включив объявление параметров шаблона в начало списка параметров функции:
[]...(typename T1, typename T2, int i, T1* pt1, const vector& v) {...}
Но на самом деле мне не нравятся две вещи. Во-первых, синтаксис — недостаточно элегантно для меня, чтобы отдавать ему предпочтение. А во-вторых, вложенные лямбды будут отрицательно сказываться на удобочитаемости кода (впрочем, этот момент мне даже в лиспе не нравился, когда мы его изучали в университете).
[]...(typename T1, typename T2, int i, T1* pt1, const vector& v) {...}
Но на самом деле мне не нравятся две вещи. Во-первых, синтаксис — недостаточно элегантно для меня, чтобы отдавать ему предпочтение. А во-вторых, вложенные лямбды будут отрицательно сказываться на удобочитаемости кода (впрочем, этот момент мне даже в лиспе не нравился, когда мы его изучали в университете).
После прочтения статьи волосы встали дыбом. C++ такой C++. В C# просто пишешь лямбду и не задумываешься, какой нафиг у переменной захват, mutable/не mutable, что такое анонимный функтор с перегруженным оператором и так далее. Неужели ЭТИМ будет кто-то всерьез пользоваться? Да тут можно таких дров наломать, что потом неделю отлаживать придется.
Программисты на С++ привыкли думать во время работы. Если для Вас это непривычно, то продолжайте C#, незачем терзать себя таким страшным языком, как С++.
*писать на C#
Зачем вы так) Я очень люблю C++ (и написал на нем много кода), просто утверждаю, что в языке стало больше на одно место, где можно эпически облажаться начинающим программистам.
Думать это правильно, но ведь зачем-то придумали абстракции, чтобы упростить жизнь нашему брату. Можно писать на ассемблере например, там очень сильно думать надо. Введению auto я очень рад, он избавляет от рутинной работы. Лямбды по идее тоже избавляют от рутинной работы, но… Когда есть с чем сравнивать, становится неловко. Если бы они появились в середине девяностых, они произвели настоящий фурор. Но не в наше время.
Думать это правильно, но ведь зачем-то придумали абстракции, чтобы упростить жизнь нашему брату. Можно писать на ассемблере например, там очень сильно думать надо. Введению auto я очень рад, он избавляет от рутинной работы. Лямбды по идее тоже избавляют от рутинной работы, но… Когда есть с чем сравнивать, становится неловко. Если бы они появились в середине девяностых, они произвели настоящий фурор. Но не в наше время.
Статься содержит ошибку. Так не разрешается
[&, x, &y] // захват всех переменных по ссылке, кроме x…
Если указан захват по умолчанию &, то все явные захваты должны быть по значению. То есть &y в данном списке не допускается.
И наоборот, если указан захват по умолчанию =, то все явные захваты должны быть по ссылке.
Изначально я предположил, что в 2009 году черновая версия спецификации не содержала такого ограничения, но несложно проверить, что это ограничение присутствовало с самого начала.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
C++0x (С++11). Лямбда-выражения