Форум на Исходниках.RU

Lisp vs C++

linuxfan — Thu, 17 Aug 2006 10:14:36 +0000

linuxfan:

Цитата Neko @ 17.08.06, 09:39

linuxfan, посмотрел я тут на ваши мегаисходники. И скока они компилируются? :rolleyes:

Какие исходники? Lisp'овские? Быстрее, чем хеловорлд на C++ :)

Lisp vs C++

Neko — Thu, 17 Aug 2006 09:39:51 +0000

Neko: linuxfan, посмотрел я тут на ваши мегаисходники. И скока они компилируются? :rolleyes:

Сравните с хорошим C++ компилером :whistle:

Lisp vs C++

linuxfan — Mon, 14 Aug 2006 13:43:43 +0000

linuxfan: Ну тогда приведи задачу, которая, на твой взгляд, очень элегантно решаема на плюсах, а я попробую ее в свободное время решить на Lisp'е.
Только большая просьба не приводить числодробилок -- неинтересно.

Lisp vs C++

BugHunter — Mon, 14 Aug 2006 13:36:51 +0000

BugHunter: А чо, давай. Как найду время. Правда, написано через задницу будет, ну так и задача соответсвует.

Lisp vs C++

linuxfan — Mon, 14 Aug 2006 13:20:28 +0000

linuxfan:

Цитата BugHunter @ 14.08.06, 13:08

Ну, в C++ тоже можно подменить функцию, подменив адрес.

Ну давай, кулхацкер, продемонстрируй подмену адреса (или переопределение) функции в C++.

Lisp vs C++

BugHunter — Mon, 14 Aug 2006 13:08:33 +0000

BugHunter:

Цитата

в силу динамической природы языка можно подменять функции прямо в runtime :)

Ну, в C++ тоже можно подменить функцию, подменив адрес. Возникает законный вопрос - зачем?.. Может я не настолько извращенец, что бы думать об этом?..

Цитата

Пока не сталкивался, но я как минимум не вижу, почему не могут быть реализованы подобного рода assert'ы и в Lisp'е.

так они ещё не реализованы? какой отсталый язык (качает головой)

Lisp vs C++

Relan — Mon, 14 Aug 2006 09:10:29 +0000

Relan:

Цитата trainer @ 13.08.06, 16:38

Язык LISP для представления выражений использует префиксный тип записи, называемый кембриджской польской записью. Такая запись в отличие от польской записи содержит скобки, ограничивающие операнды, на которые действует операция. Таким образом, в кембриджской польской записи выражение представляет собой множество вложенных подвыражений, ограниченных скобками.

Называть это префиксной записью -- это слишком упрощенно. Наверное в том тексте посчитали такое упрощение допустимым. На самом деле всё несколько сложнее, по этому поводу см. любой учебник по Лиспу, где разбирается математический аппарат, лежащий в основе языка. Правильнее думать о выражениях Лиспа как о списках, каковыми они собственно и являются. Ну и еще необходимо упомянуть про QUOTE.

Lisp vs C++

linuxfan — Sun, 13 Aug 2006 21:11:45 +0000

linuxfan:

Цитата BugHunter @ 13.08.06, 20:57

2) Что такое умеет отладчик lisp-а, что не умеет отладчик MSVC++ или DDD?

Он умеет одну простую вещь: в силу динамической природы языка можно подменять функции прямо в runtime :) Если бы ПО спутника написали на C++, то при исправлении ошибок его бы пришлось перезапускать.

Цитата BugHunter @ 13.08.06, 20:57

В LISP-е удобнее? Правда что ли?

Пока не сталкивался, но я как минимум не вижу, почему не могут быть реализованы подобного рода assert'ы и в Lisp'е. Там все очень продумано. Почитай ради любопытства «Practical Common Lisp» после третьей главы мне захотелось прочитать все остальное :) Очень уж элегантен Lisp-way.

Добавлено 13.08.06, 21:12

Цитата BugHunter @ 13.08.06, 20:57

В Стандарт попадает много всякого разного, в т.ч. сомнительной полезности.

Тем не менее, если STL -- часть стандарта, то => STL -- часть языка.

Lisp vs C++

BugHunter — Sun, 13 Aug 2006 20:57:56 +0000

BugHunter:

Цитата

Или ты гений и провидец, или программа не сложнее «hello world». Поведение большинства современных программ очень трудно предсказать, т. к. они многоточные и довольно запутанные.

Ну, многопотоковость - это ещё один жупел (так же как и кроссплатформенность).
К счастью, её у меня нет. Ни к чему она мне. Не, я не гений (к счастью). И не провидец (тоже к счастью). Просто, догадливый.

Цитата

Там более азвитые средства для обнаружения ошибок.

1) Что значит развитые средства? Отладчика уже недостаточно?
2) Что такое умеет отладчик lisp-а, что не умеет отладчик MSVC++ или DDD?
3) assert( a != 0 && a < 200 ); По моему всё понятно и довольно тупо, ошибиться невозможно. 99,9% случаев пользователь нарывается на такой ассерт, программа не падает и продолжает работать дальше. (ну, есть ещё 0.1%, когда ассерт поставить я забыл или ещё чего то не предусмотрел)
Прочитав в рекламации "что делали" и "какой ассерт получили" сразу же получаем сценарий неправильного поведения и условие, которому перестал удовлетворять наш a. Имя файла и номер строки, где предположительно дело пошло не так, как надо. Открою маленький секрет - чаще всего мне даже не приходится повторять ошибку руками, т.к. по ассерту и так всё ясно.

В LISP-е удобнее? Правда что ли?

Цитата

STL -- уже часть стандарта C++, ходят слухи, что значительная часть boost попадет в новый стандарт C++.

В Стандарт попадает много всякого разного, в т.ч. сомнительной полезности. Это не значит, что мы обязаны использовать ВЕСЬ язык (или всё таки обязаны?).

Lisp vs C++

linuxfan — Sun, 13 Aug 2006 20:23:22 +0000

linuxfan:

Цитата BugHunter @ 13.08.06, 20:09

Поведение программы понятно из одного только прочтения её кода :yes:

Цитата BugHunter @ 13.08.06, 20:09

В динамических языках, я так подозреваю, это совсем не так.

В динамических все, как правило, намного легче. Там более азвитые средства для обнаружения ошибок.

Цитата BugHunter @ 13.08.06, 20:09

А я и не включал STL или boost в число удобных библиотек.

STL -- уже часть стандарта C++, ходят слухи, что значительная часть boost попадет в новый стандарт C++. «Ежики плакали, кололись, но продолжали есть кактус» ©

Lisp vs C++

BugHunter — Sun, 13 Aug 2006 20:09:29 +0000

BugHunter:

Цитата

Ничо, мне после МК-52 и не такое понятно...

Да уж, машинка была жестяная. Мне по счастью в руки попал сразу буржуйский "Гражданин", повёрнутый к пользователю своим фейсом, а не другими частями тела :)

Цитата

Рассказывают, что даже дебажили Lisp'овую программу управления спутником с Земли... удаленно дебажили, при этом в процессе отладки ничего не пострадало и не остановилсь. Вот это, я понимаю, модульность.

И что?.. Не пострадало и не остановилось - я тоже так могу :yes: Правда, перекомпилять потом придётся, но это мелочи жизни.
А вообще мне даже дебажить чаще всего не нужно. Я и так знаю, как у меня что работает. Мне даже тесты в 99% случаев не нужны. Поведение программы понятно из одного только прочтения её кода :yes:
В динамических языках, я так подозреваю, это совсем не так. Я прав?

Цитата

Все идеологически правильно и выдержано, не то что в це-крест-крест: это функция, а вот это оператор, а вот это вообще метод, а вот тут dynamic_cast мы придумали, но старайтесь избегать его использования,

Жгучее желание использовать dynamic_cast - на лицо явная ошибка проектирования. Остановить и перепиши код.
Для всех операторов так же есть рекомендованная семантика (должен ли быть методом или отдельной функцией и т.д.), здесь я проблем не вижу.

Цитата

а вот ту у нас контейнеры, но не для всех существуют определенные методы и пр. Про «читаемость» STL headers -- отдельная песня. А уж какие ошибки компилер временами пишет... Жесть!

А я и не включал STL или boost в число удобных библиотек.

Lisp vs C++

Ho Im — Sun, 13 Aug 2006 19:53:59 +0000

Ho Im:

Цитата BugHunter @ 13.08.06, 19:45

нифига Lisp не идеально читается, а
+ x y
это вообще жесть. Как там это называется?.. Польская запись что ли?..
Ну так это для приближения к машине, не нужно называть такие вещи "интуитивно понятными" и т.п.

Ничо, мне после МК-52 и не такое понятно...

Lisp vs C++

linuxfan — Sun, 13 Aug 2006 19:51:09 +0000

linuxfan: Да ладно, не так ты читаешь: Lisp -- функциональный язык и на первом месте стоит вызов функции с именем '+' (можно даже ее адрес получить, если надо).
Все идеологически правильно и выдержано, не то что в це-крест-крест: это функция, а вот это оператор, а вот это вообще метод, а вот тут dynamic_cast мы придумали, но старайтесь избегать его использования, а вот ту у нас контейнеры, но не для всех существуют определенные методы и пр. Про «читаемость» STL headers -- отдельная песня. А уж какие ошибки компилер временами пишет... Жесть!
То ли дело Lisp. Рассказывают, что даже дебажили Lisp'овую программу управления спутником с Земли... удаленно дебажили, при этом в процессе отладки ничего не пострадало и не остановилсь. Вот это, я понимаю, модульность.

Добавлено 13.08.06, 19:52
А «не определился» больше для C++ подходит: и не импиративный, да и до объектного еще вроде как не дорос. Нечто аморфно-неопределенное.

Lisp vs C++

BugHunter — Sun, 13 Aug 2006 19:45:39 +0000

BugHunter: в тему:

Цитата

-ты мальчик или девочка?
-я ещё не определился.

Lisp vs C++

trainer — Sun, 13 Aug 2006 16:38:28 +0000

trainer: http://www.intuit.ru/department/pl/plintro/3/

Цитата

http://en.wikipedia.org/wiki/Lisp_programming_language

Цитата

Expressions are written as lists, using prefix notation.

Кому верить? ;) :D

Lisp vs C++

Relan — Sun, 13 Aug 2006 15:56:26 +0000

Relan:

Цитата trainer @ 13.08.06, 08:12

Ну да, что-то меня переклинило, это префиксная запись
Инфиксная - это традиционная математическая

Поверь мне на слово, это и не префиксная запись тоже. :) Это S-выражение.

Lisp vs C++

trainer — Sun, 13 Aug 2006 08:12:02 +0000

trainer:

Цитата Relan @ 12.08.06, 12:42

Это не инфиксная запись, это S-выражение

Ну да, что-то меня переклинило, это префиксная запись :D
Инфиксная - это традиционная математическая :D

Lisp vs C++

Relan — Sat, 12 Aug 2006 14:35:05 +0000

Relan:

Цитата linuxfan @ 12.08.06, 13:20

Я тоже, но многим математикам функциональное программирование будет намного роднее императивного.

Угу. :yes: Что вполне естественно. В императивном программировании очень извратили понятие переменной.

Сейчас читаю литературу по Хаскелю. Прикольный язык. Одного не понимаю: почему монадические операции считаются чистыми? haskell.ru мне этого не прояснил. Буду признателен, если кто-нибудь растолкует на пальцах.

Lisp vs C++

linuxfan — Sat, 12 Aug 2006 13:20:24 +0000

linuxfan:

Цитата Relan @ 12.08.06, 12:42

Сам от этого страдаю. :(

Я тоже, но многим математикам функциональное программирование будет намного роднее императивного.

Lisp vs C++

Relan — Sat, 12 Aug 2006 12:42:02 +0000

Relan:

Цитата trainer @ 12.08.06, 11:57

А что такое + x y? Это ж еще объяснить надо про инфиксную запись.

Это не инфиксная запись, это S-выражение. :)

На самом деле синтаксис Лиспа очень прост, но въехать в функциональное программирование людям, отягощенным опытом императивного программирования, очень тяжело. Сам от этого страдаю. :(

Lisp vs C++

trainer — Sat, 12 Aug 2006 11:57:58 +0000

trainer:

Цитата linuxfan @ 12.08.06, 06:41

Человеку, далекому от программирования Lisp ИМХО будет выглядеть понятнее.

Человеку, далекому от программирования это будет темный лес.

Цитата linuxfan @ 12.08.06, 06:41

Читается идеально:

Может быть идеально, когда знаешь. А когда нет - берешь словарь и разбираешь:
for x = 0 then y | для x=0 затем/потом/тогда y
Что затем y? Или что потом y? x затем y? Или просто затем y? А зачем(когда) затем? Или когда тогда?
and y = 1 then (+ x y) | и y=1 затем/потом/тогда (+ x y)
Аналогично. А что такое + x y? Это ж еще объяснить надо про инфиксную запись.
Оно и dcfsnz x,1 читается идеально, когда знаешь, что это. :)

Lisp vs C++

linuxfan — Sat, 12 Aug 2006 06:41:00 +0000

linuxfan: ~a == aesthetic (печать аргумента в красивом виде)
~% == \n
Все остальное понятно, потому что там, где в C/C++/Pascal применяют хитрые языковые конструкции, в Lisp'е пишут чуть ли не на естественном языке. Фнукциональные языки, как правило, позволяют писать более выразительный и понятный код.

Добавлено 12.08.06, 06:52

Цитата BugHunter @ 11.08.06, 22:03

Вот, например, код на Java или C# или даже Pascal - мне понятен всегда, несмотря на то, что я никогда их не изучал специально.

Так они все похожи как сиамские близнецы. Человеку, далекому от программирования Lisp ИМХО будет выглядеть понятнее.
Зацени подсчет чисел Фибоначчи:

(loop repeat 5

for x = 0 then y

and y = 1 then (+ x y)

collect y)

Читается идеально:
repeat 5: повторям цикл пять раз;
for x=0 then y: изначально x приравниваем к 0, а на каждой последующей итерации присваиваем x значение y
and y = 1 then (+ x y): а y изначально приравниваем к 1, а на каждой последующей итерации присваиваем y значение x+y
collect y: результатом выполнения цикла будет список из значений y
Думаю, плюсовые заморочки были бы менее очевидными.

Lisp vs C++

Ho Im — Fri, 11 Aug 2006 23:15:23 +0000

Ho Im:

Цитата BugHunter @ 11.08.06, 22:03

что здесь хотел афтор - хрен его не разберёт, а я даже и пытаться не буду.

Я со всего только форматную строку не понял, ибо не ртфмил. Все остальное как на ладошке.

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 22:28:11 +0000

Flex Ferrum:

Цитата BugHunter @ 11.08.06, 21:54

а какие нибудь классики, то тут начинается беда с биндерами и пр. mem_fun_ref, что ОФИГЕННО добавляет читаемости в коде (злая шутка).

Ну так сейчас mem_fun_ref'ами никто практически и не пользуется. Все больше boost::bind'ерами... Но ты ведь boost не пользуешь - тебе нельзя... :)

Цитата BugHunter @ 11.08.06, 21:54

Я и на русском, и на буржуйском бью 250 знаков в минуту, так что фигня война.
Реализация непосредственно алгоритма занимает процентов 15-20% времени (максимум), затраченного на задачу.

Дело не в том, как быстро ты (или я) по клаве стучишь, а в том, какими сущностями оперируешь. Я оперирую алгоритмами. Ты (судя по всему) - простыми языковыми конструкциями...

Lisp vs C++

BugHunter — Fri, 11 Aug 2006 22:03:45 +0000

BugHunter: ну да, ну да.

(defun make-logger (filename)

(let ((log (open filename

:direction :output

:if-does-not-exist :create

:if-exists :append)))

(values

(lambda (string)

(format log "~a~%" string))

(lambda ()

(close log)))))

что здесь хотел афтор - хрен его не разберёт, а я даже и пытаться не буду. Вот, например, код на Java или C# или даже Pascal - мне понятен всегда, несмотря на то, что я никогда их не изучал специально.

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 21:59:59 +0000

linuxfan:

Цитата BugHunter @ 11.08.06, 21:58

Сосредоточимся на задачах, а не языковых средствах и синтаксических сахарах.

Lisp как раз и позволяет это сделать, в отличие от... :)

Lisp vs C++

BugHunter — Fri, 11 Aug 2006 21:58:13 +0000

BugHunter: Почему оффтоп?
Перевожу последние свои посты на русский.
Lisp ф топку, и извращённый C++ - туда же. Сосредоточимся на задачах, а не языковых средствах и синтаксических сахарах.

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 21:56:35 +0000

linuxfan: Блин, опять в оффтоп скатились чтоли?

Lisp vs C++

BugHunter — Fri, 11 Aug 2006 21:54:06 +0000

BugHunter:

Цитата

BugHunter, а твоя мегаконструкция связанные списки обработает? Все так же понятно?

Связные списки она не обработает. ПОтому что они не поддерживают random access iterator. И фигли? Но этого и не было в начальном условии. Ну хоспади, заменил бы i на std::list<...>::iterator, Size() на .end(), и всё ништяк.

Цитата

В моем случае - одна, в которой явно указывается производимая операция.

Тут главное, не увлечься. Поскольку плоский int я храню в контейнерах нечасто (точнее, часто, но над ними извращений не делается), а какие нибудь классики, то тут начинается беда с биндерами и пр. mem_fun_ref, что ОФИГЕННО добавляет читаемости в коде (злая шутка).

Добавлено 11.08.06, 21:56

Цитата

Только тебе нужно 5 строчек

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 21:16:01 +0000

Flex Ferrum: И еще скажи, что этот код не понятен, и не читабелен. Для того, чтобы понять, что делает твой код, мне нужно просмотреть 3 строчки (for + if + break). В моем случае - одна, в которой явно указывается производимая операция. Почувствуй разницу.

Lisp vs C++

Ho Im — Fri, 11 Aug 2006 21:15:12 +0000

Ho Im: BugHunter, а твоя мегаконструкция связанные списки обработает? Все так же понятно?

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 21:14:29 +0000

Flex Ferrum:

Цитата BugHunter @ 11.08.06, 20:56

Посмотрю я на код через .. ну скаже, 10 лет. И всё будет понятно.

Угумс... Угумс... Только тебе нужно 5 строчек для того, для чего мне потребуется 1, и эта одна будет работать несколько эффективней и быстрее:

vector<...>::iterator p = std::find_if(vec.begin(), vec.end(), CheckCondition);

Lisp vs C++

BugHunter — Fri, 11 Aug 2006 20:56:05 +0000

BugHunter: Как там было у классика?.. "Горе от ума"?
Все эти for_each и т.п. лямбды понятности в код не добавляют.
Короче, я так и не понял, куда это - ф сад или ф топку.

...
ну, вот например:

Цитата

for( int i = 0; i < vec.Size(); i++ ) {
if( CheckCondition( vec[i] ) ) {
break;
}
}

Посмотрю я на код через .. ну скаже, 10 лет. И всё будет понятно. Чего не скажешь о прожжоном STL коде.
Да, если особо не злоупотреблять, то он будет таким же понятным. И почти без накладных расходов.
именно за это я люблю C++ + STL::контейнеры.

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 19:55:04 +0000

linuxfan: Пардон, вспомнил, что адекватные, но ограниченные.

Lisp vs C++

best_lamer — Fri, 11 Aug 2006 19:44:53 +0000

best_lamer:

Цитата linuxfan @ 11.08.06, 15:00

Кстати, лямбды в питоне, кажется есть и вроде даже адекватные.

В глубь языка Python

Цитата

Python поддерживает интересный синтаксис, позволяющий определять небольшие однострочные функции на лету. Позаимствованные из Lisp, так назыаемые lambda-функции могут быть использованы везде, где требуется функция.

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 19:40:42 +0000

linuxfan:

Цитата Red Devil @ 11.08.06, 19:28

Все основные знаю, или по крайне мере знаком как с asm.

Назови, плз ;)
Вот список того, о чем я имею представление:
C, C++, Pascal (сюде идет и Delphi), Java, basic (в т. ч. и с vba забавлялся), perl, php, python, bash (а чем не язык ;)), JavaScript, Rebol (было дело :), Lisp, Fortran, Assembler x86 (хоть для real mode, хоть для pm32; как intel'овский, так и AT'шный синтаксис).
И вроде как получается Lisp с любым потягаться может. Не по скорости, конечно (хотя джаву, vba, perl, php, python, bash, javascript и rebol по скорости уделает без вопросов; с остальными может почти на равных быть, если icc в расчет не брать), но по удобству или хотя бы по красоте.

Lisp vs C++

Red Devil — Fri, 11 Aug 2006 19:28:15 +0000

Red Devil: linuxfan

Цитата

Или ты серьезно

Сурьезно.

Цитата

Ты так много инструментов разработки знаешь, чтобы такие выводы делать?

Все основные знаю, или по крайне мере знаком как с asm.

Цитата

Забабахай-ка мне на quick sort double'ов на асме

Я не могу полностью писать программы на asm. Только мелкие вставки. Прадва в скором времени исправлю этот недостаток.

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 18:46:01 +0000

linuxfan:

Цитата trainer @ 11.08.06, 18:18

Можно создать proxy-класс, перегрузить для него, например, operator<< и использовать примерно в таком стиле:

А лишние накладные расходы, в т. ч. и на работу с прокси-классом и на написание прокси-классов для каждой функции?

Lisp vs C++

trainer — Fri, 11 Aug 2006 18:18:22 +0000

trainer:

Цитата linuxfan @ 11.08.06, 17:03

А мне понадобилось законнектиться к localhost (host=NULL) без пароля, но к нестандартному порту 8765. У меня просто нет другого выхода, кроме как описать все параметры.

Можно создать proxy-класс, перегрузить для него, например, operator<< и использовать примерно в таком стиле:

connect(default_connection_params()<<conn_port(8756));

или даже так:

connect(conn_port(8756));

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 18:04:46 +0000

linuxfan:

Цитата Red Devil @ 11.08.06, 18:02

У С++ есть только один конкурент - asm.

Юмор прочитал. Шутку оценил.
Или ты серьезно :blink:
Ты так много инструментов разработки знаешь, чтобы такие выводы делать? :lol:
Забабахай-ка мне на quick sort double'ов на асме :D А потом говори кто кому конкурент :D

Добавлено 11.08.06, 18:10
Желяющие померяться мультиметодами будут? ;)

Lisp vs C++

Red Devil — Fri, 11 Aug 2006 18:02:59 +0000

Red Devil: У С++ есть только один конкурент - asm. Все остальное (тем более Лисп) и рядом не валялось.

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 17:55:11 +0000

linuxfan: А еще в lisp'е совершенно другой подход к ООП, поэтому там возможно легко и естественно делать мультиметоды (интересующимся рекомендую просто почитать про этот паттерн).

Lisp vs C++

mo3r — Fri, 11 Aug 2006 17:27:02 +0000

mo3r:

Цитата linuxfan @ 11.08.06, 17:03

И наглядно, и понятно, и удобно.

В целом, да, но можно сделать перегрузки для различных комбинаций (но оно, конечно, будет менее удобно).

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 17:03:52 +0000

linuxfan: Кстати, вот такой вот изврат в lispe'е можно осуществить:
функция, возвращающая список из двух функций, одна из которых пишед в заданный файл, а другая -- закрывает его.
Тут демонстируется то, что называется «lexical closure»

(defun make-logger (filename)

(let ((log (open filename

:direction :output

:if-does-not-exist :create

:if-exists :append)))

(values

(lambda (string)

(format log "~a~%" string))

(lambda ()

(close log)))))

А вот так помле этого можно создавать функции, работающие с этим файлом (меня просто прикалывает этот изврат :D):

(mapcan

#'(lambda (name body)

(setf (fdefinition name) body))

'(my-log my-log-close)

(multiple-value-list (make-logger "/tmp/out.log")))

Ессно, это полный изврат и так никто не делает. В этом случае в C++ создавать экземпляры классов с определенными методами, но тут другой интересный факт: лексическое связывание осуществляется в runtime. И это еще без макросов :)

Добавлено 11.08.06, 17:12

Цитата Flex Ferrum @ 11.08.06, 16:55

count в данном случае для того, чтобы цикл не организовывать.

:yes: Но его ведь можно и не указывать :)
Покажи мне в C++ аналог именуюемых параметров.
Со значениями по умолчанию -- есть, vararg'и (...) есть, а вот аналога &key нету.
Допустим, есть некая ф-ция подсоединения к БД, которая принимает на вход хост, логин, пароль и порт, причем хост, пароль и порт имеют значения по умолчанию, и пусть функция коннекта выглядит так (const не пишу из лени):

DBconnection *connect (char *login,char *pass=NULL,char *host=NULL,int port=5432)

А мне понадобилось законнектиться к localhost (host=NULL) без пароля, но к нестандартному порту 8765. У меня просто нет другого выхода, кроме как описать все параметры.
Lisp-way:

(defun connect (login &key pass host (port 5432)) (...))

И вызов:

(connect "mylogin" :port 8765)

И наглядно, и понятно, и удобно.

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 16:55:36 +0000

Flex Ferrum:

Цитата linuxfan @ 11.08.06, 16:50

Ну хотя бы тем, что он умеет "count"

И что? Методы типа erase тоже умеют удалять заданное количество элементов. count в данном случае для того, чтобы цикл не организовывать. Разве нет?

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 16:50:51 +0000

linuxfan: Ну хотя бы тем, что он умеет "count" :)

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 16:34:10 +0000

Flex Ferrum:

Цитата linuxfan @ 11.08.06, 16:28

delte просто будет «покруче» плюсовых remove_if (кстати, в list и такое есть :))

А чем именно?

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 16:28:13 +0000

linuxfan: Не совсем так: delte просто будет «покруче» плюсовых remove_if (кстати, в list и такое есть :))

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 16:10:08 +0000

Flex Ferrum:

Цитата linuxfan @ 11.08.06, 16:00

delete -- вызов функции delete (стандартная лисповская)
затем идут два ее параметра: 0 (это то, чему должна равняться значение ключевой функции), затем a -- сам список.
После этого идут keyword parameters (по-русски ИМХО это ближе всего к именованным параметрам):
:cout 4 -- число удалений
:from-end t -- булевый параметр, указывающий на то, что список надо ворошить с хвоста
:key а тут надо предоставить функцию получения значения ключа; в качестве параметра передается элемент списка

Т. е. в (не)монструозности лямбда-функции ни при чем. Ибо если бы небыло некоторых ограничений на предикаты (как то ограничение на сохранение состояния), то на С++ это тоже бы в одну строчку уместилось...

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 16:00:37 +0000

linuxfan:

Цитата Flex Ferrum @ 11.08.06, 15:49

Вопрос из за того, что с синтаксисом лиспа я не знаком.

Не вопрос:
delete -- вызов функции delete (стандартная лисповская)
затем идут два ее параметра: 0 (это то, чему должна равняться значение ключевой функции), затем a -- сам список.
После этого идут keyword parameters (по-русски ИМХО это ближе всего к именованным параметрам):
:cout 4 -- число удалений
:from-end t -- булевый параметр, указывающий на то, что список надо ворошить с хвоста
:key а тут надо предоставить функцию получения значения ключа; в качестве параметра передается элемент списка
#' -- это что-то вроде операции взятия адреса функции (применимо только к функциям)
а дальше идет сама лямбда-функция:
(lambda (x) (mod x 3)) -- берет один аргумент, возвращает остаток от деления аргумента на 3.
Ну а потом закрываются все скобки :)

Lisp vs C++

mo3r — Fri, 11 Aug 2006 15:57:52 +0000

mo3r:

Цитата linuxfan @ 11.08.06, 15:46

Но все-таки тут нед лямбда-функций в чистом виде.

Что значит --- в чистом виде? boost::lambda позволяет делать лямбды с if-ами, тернарным оператором, с киданием-ловлей исключений, с switch-case, for, while, do-while, конструкторами, деструкторами. Только goto нету (AFAIK).

Добавлено 11.08.06, 15:58

Цитата Flex Ferrum @ 11.08.06, 15:55

Не, не проканает. Предикат не имеет право иметь состояние. А в данном случае count - это состояние предиката, хоть и неявное.

Хм. Действительно...

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 15:55:58 +0000

Flex Ferrum:

Цитата mo3r @ 11.08.06, 15:51

Значит, я неправильно понял.

Lisp vs C++

mo3r — Fri, 11 Aug 2006 15:51:48 +0000

mo3r:

Цитата linuxfan @ 11.08.06, 15:31

mo3r, э нет. Это удалит все элементы, кратные трем из последних четырех.

Значит, я неправильно понял.

using namespace boost::lambda;//в прошлых примерах я забыл про это

std::vector<int> vec;

int count = 0;

vec.erase(

std::remove_if(

vec.rbegin(),

vec.rend(),

(_1 % 3) == 0 && var(count)++ < 4

vec.end()

);

Цитата linuxfan @ 11.08.06, 15:31

Может в соседнюю тему переедем? Там вы меня попросите что-нибудь изобразить :)
Только не слишком сложное -- lisp это хобби :)

Тут уж я вряд ли смогу что-то сказать :) . Лисп я не особо знаю, но, думаю, что там можно многое.

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 15:49:13 +0000

Flex Ferrum:

Цитата linuxfan @ 11.08.06, 15:46

Но все-таки тут нед лямбда-функций в чистом виде. Это больше похоже на частный случай для предикатов.

А что значит "лямда-функций в чистом виде"? Вопрос из за того, что с синтаксисом лиспа я не знаком. По этому если ты пояснишь что какая конструкция в твоей строчке:

Цитата linuxfan @ 11.08.06, 15:25

(delete 0 a :count 4 :from-end t :key #'(lambda (x) (mod x 3)))

обозначает - будет здорово.

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 15:46:33 +0000

linuxfan: Я так и знал, что в плюсах это будет выглядеть более монструозно.
Кстати, я бы соптимизировал ;)

for (int n = 0; n < 4; ++ n)

{

std::vector<int>::reverse_iterator p = std::find_if(v.rbegin(), v.rend(), (_1 % 3) == 0);

if (p != v.rend())

v.erase((++p).base());

else

break;

}

Но все-таки тут нед лямбда-функций в чистом виде. Это больше похоже на частный случай для предикатов.

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 15:39:42 +0000

Flex Ferrum:

Цитата linuxfan @ 11.08.06, 15:31

Я прошу четыре последних элемента, кратные трем.

for (int n = 0; n < 4; ++ n)

{

std::vector<int>::reverse_iterator p = std::find_if(v.rbegin(), v.rend(), (_1 % 3) == 0);

if (p != v.rend())

v.erase((++p).base());

}

Это сообщение было перенесено сюда или объединено из темы "Python vs Delphi"

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 15:31:43 +0000

linuxfan: mo3r, э нет. Это удалит все элементы, кратные трем из последних четырех.
Я прошу четыре последних элемента, кратные трем.
Может в соседнюю тему переедем? Там вы меня попросите что-нибудь изобразить :)
Только не слишком сложное -- lisp это хобби :)

Это сообщение было перенесено сюда или объединено из темы "Python vs Delphi"

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 15:28:59 +0000

linuxfan: Что вам хочется увидеть из того, что на ваш взгляд элегеантно реализуется в плюсах?

Lisp vs C++

mo3r — Fri, 11 Aug 2006 15:28:58 +0000

mo3r:

Цитата linuxfan @ 11.08.06, 15:25

А теперь удалять только последние 4, кратные трем :)

Это, конечно, к лямбдам не относится, а скорее к алгоритмам, но...

std::vector<int> vec;

vec.erase(

std::remove_if(

vec.size()<4?vec.begin():vec.end()-4,

vec.end(),

(_1 % 3) == 0

vec.end()

);

Это сообщение было перенесено сюда или объединено из темы "Python vs Delphi"

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 15:25:44 +0000

linuxfan: А теперь удалять только последние 4, кратные трем :)
Думаю, что беспокойство доставит удалить именно «последние четыре» :)
Мне интересно, как это выглядит. Насколько близко это будет по простоте к

(delete 0 a :count 4 :from-end t :key #'(lambda (x) (mod x 3)))

Добавлено 11.08.06, 15:26

Цитата Flex Ferrum @ 11.08.06, 15:21

Дабы не было кивков в сторону "накладных расходов". :)

Сейчас я к накладным расходам придираться не буду, ибо в lisp'е их по определению больше.

Это сообщение было перенесено сюда или объединено из темы "Python vs Delphi"

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 15:21:10 +0000

Flex Ferrum:

Цитата linuxfan @ 11.08.06, 15:04

Приведи пример кода, удаляющий все четные элементы из вектора с лямбдами.

Пожалуйте:

using namespace lambda;

std::vector<int> v(20);

for (int n = 0; n < v.size(); ++ n)

v[n] = n;

std::for_each(v.begin(), v.end(), std::cout << _1 << "\n");

std::cout << std::endl;

v.erase(std::remove_if(v.begin(), v.end(), (_1 % 2) == 0), v.end());

std::for_each(v.begin(), v.end(), std::cout << _1 << "\n");

Выдает законные:

Добавлено 11.08.06, 15:24
Если интересно - приведу ассемблерный листиг любого из for_each. Дабы не было кивков в сторону "накладных расходов". :)

Это сообщение было перенесено сюда или объединено из темы "Python vs Delphi"

Lisp vs C++

mo3r — Fri, 11 Aug 2006 15:16:21 +0000

mo3r:

Цитата linuxfan @ 11.08.06, 15:04

Кстати, а в каком языке лямбда может быть lecsical closure (т. е. захватывать биндинги из точки основания)? Мне на ум приходит только Java с ее anonymous (так чтоли называются?) классами.

Например, в тех же плюсах. Используя boost::lambda::var, boost::lambda::constant, boost::lambda::constant_ref.

Цитата linuxfan @ 11.08.06, 15:04

Приведи пример кода, удаляющий все четные элементы из вектора с лямбдами.

std::vector<int> vec;

vec.erase(

std::remove_if(

vec.begin(),

vec.end(),

_1 % 2 == 0

vec.end()

);

Это сообщение было перенесено сюда или объединено из темы "Python vs Delphi"

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 15:04:11 +0000

linuxfan: Кстати, а в каком языке лямбда может быть lecsical closure (т. е. захватывать биндинги из точки основания)? Мне на ум приходит только Java с ее anonymous (так чтоли называются?) классами.
А в плюсах лямбды -- это чистой воды костыль.
C++ и Delphi вообще языки с полустатической типизацией. Как их можно с Python сравнивать?

Добавлено 11.08.06, 15:05

Цитата Flex Ferrum @ 11.08.06, 15:02

Ткни пальцем в уродливость...

Приведи пример кода, удаляющий все четные элементы из вектора с лямбдами.

Это сообщение было перенесено сюда или объединено из темы "Python vs Delphi"

Lisp vs C++

Flex Ferrum — Fri, 11 Aug 2006 15:02:15 +0000

Flex Ferrum:

Цитата linuxfan @ 11.08.06, 15:00

Выглядит эта возможность именно костылем. Уродливо т. е.

Ткни пальцем в уродливость...

Это сообщение было перенесено сюда или объединено из темы "Python vs Delphi"

Lisp vs C++

linuxfan — Fri, 11 Aug 2006 15:00:11 +0000

linuxfan:

Цитата Flex Ferrum @ 11.08.06, 13:48

Это означает, что эти функции могут быть реализованы средставми языка.

Знаешь, на ассемблере ведь тоже можно написать веб-сервер, но что-то никто желания пока не изъявлял.
Спасибо, но меня воротит от плюсового синтаксиса в области шаблонов. Я асм легче читаю, чем такой код.

Цитата Flex Ferrum @ 11.08.06, 13:48

По этому про "костыли" - не надо.

Выглядит эта возможность именно костылем. Уродливо т. е.

Раз уж все равно в оффтоп скатились, может, померяемся стандартными библиотеками?
Как там у вас в плюсах/дельфях/питоне удаляют элементы из контейнера?
Хочу удалить четыре последних элемента, кратных трем.
Прошу заметить, что первая строчка всего лишь инициализирует последовательность.

(setq a (loop for i from 1 to 32 collect i))

(remove 0 a :count 4 :from-end t :key #'(lambda (x) (mod x 3)))

Ну давайте ваши лямбды сюда!

Добавлено 11.08.06, 15:01
Кстати, лямбды в питоне, кажется есть и вроде даже адекватные.

Это сообщение было перенесено сюда или объединено из темы "Python vs Delphi"