2 softwarer:

softwarer
Когда-то существовало понятие вложенных, или локальных, подпрограмм.

Локальные процедуры/функции и сейчас есть -- в Delphi. И это удобно.

softwarer
После чего прошло еще несколько лет, и концепцию возродили в виде вложенных объектов, или - в C++ - локальных структур.

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

2 Gluk (Kazan):

Gluk (Kazan)
Пётр СедовЛокальные процедуры/функции и сейчас есть -- в Delphi. И это удобно.
А замыкания есть в Delphi ?

Нет, ведь Delphi -- язык не функциональный (а императивный), к тому же с ручным управлением памятью (а удобные замыкания можно сделать только в языке с автоматическим управлением памятью).

Gluk (Kazan)
Или на любой Чих будет AV ?

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

Если локальная процедура/функция избегает указателей, то я не вижу как можно получить access violation. А если процедура/функция работает с указателями, то тут уж не важно, локальная она или нет, риск access violation присутствует, это неизбежная плата за указатели.

То есть в Delphi локальные процедуры/функции не повышают риск access violation.

Gluk (Kazan)
Удобно ? вряд ли.

Локальные процедуры/функции -- это действительно удобно, и в VCL они широко используются, чтобы структурировать код.

Gluk (Kazan)
Не так сложно реализовать вложенные функции в C++ как бороться с последствиями такой реализации

Из-за отсутствия в C++ нормальных локальных функций (которым легко доступен контекст, например локальная переменная охватывающей функции), их приходится эмулировать, передавая указатель на контекст в обычную (нелокальную) функцию. А там, где появился указатель, действительно и до access violation недалеко (хотя в данном случае маловероятно).

2 Gluk (Kazan):

Gluk (Kazan)
Пётр Седов
Gluk (Kazan)
Пётр СедовЛокальные процедуры/функции и сейчас есть -- в Delphi. И это удобно.
А замыкания есть в Delphi ?

Нет, ведь Delphi -- язык не функциональный (а императивный), к тому же с ручным управлением памятью (а удобные замыкания можно сделать только в языке с автоматическим управлением памятью).

О как o O. А Perl давно функциональным стал ???

Из моих слов не следует, что Perl -- функциональный язык. Но функциональный стиль ему не чужд. В Wikipedia в статье про Perl написано:
Wikipedia
Perl
...
Overview
...
Its major features include support for multiple programming paradigms (procedural, object-oriented, and functional styles), ...

В отличие от Delphi, в Perl-е автоматическое управление памятью, поэтому язык может предоставить удобные замыкания.

Gluk (Kazan)
Пётр Седов
Delphi запрещает брать адрес локальных процедур/функций. Поэтому их нельзя вызвать динамически (по указателю), можно только статически (по имени).

Ну и толку тогда от них ? Синдром шоколадного чайника ???

Толк от локальных процедур/функций такой же, как от раскладывания файлов или писем по папкам -- структуризация. Она важна, когда этих процедур/функций/файлов/писем становится много.

И ещё локальные процедуры/функции избавляют от возни с указателями на контекст.

Gluk (Kazan)
Пётр Седов
Локальные процедуры/функции -- это действительно удобно, и в VCL они широко используются, чтобы структурировать код.

Локальные функторы - это ТОЖЕ удобно :)

C++-ные локальные функторы -- менее удобная вещь, чем Delphi-йские локальные процедуры/функции, из которых легко использовать контекст (например, локальную переменную охватывающей процедуры/функции).

К тому же, C++-ный локальный функтор нельзя скормить STL-алгоритму (и вообще, любому шаблону).

2 Gluk (Kazan):

Gluk (Kazan)
Пётр СедовНет, ведь Delphi -- язык не функциональный (а императивный)
...
Из моих слов не следует, что Perl -- функциональный язык.

Странно :) Ну не следует так не следует :)

А что странного? Я утверждаю:
Delphi -- не функциональный язык.
Delphi -- императивный язык.
Разве из этих утверждений следует, что Perl -- функциональный язык?
Создатели Delphi не стремились обеспечить поддержку функционального стиля, поэтому в Delphi и нет замыканий. Да и не сделать удобные замыкания в языке с ручным управлением памятью.

Gluk (Kazan)
Пётр Седов
Но функциональный стиль ему не чужд.

С++ тоже ... не чужд (в отличии от Delphi)

На C++ писать в функциональном стиле очень неудобно. Требуются 10-этажные шаблоны вроде Boost.Lambda. И компилируется это 2 часа.

В C++ так же ручное управление памятью, поэтому удобных замыканий тоже не сделать.

Gluk (Kazan)
Пётр Седов
К тому же, C++-ный локальный функтор нельзя скормить STL-алгоритму (и вообще, любому шаблону).

А в Delphi можно ?

Это не к «C++-ный локальный функтор vs. Delphi-йская локальная процедура/функция», а просто к неудобству C++-ного локального функтора, безотносительно к другим языкам. Слишком ограниченный он.

2 Gluk (Kazan):

Gluk (Kazan)
Пётр СедовСоздатели Delphi не стремились обеспечить поддержку функционального стиля, поэтому в Delphi и нет замыканий. Да и не сделать удобные замыкания в языке с ручным управлением памятью.

Давайте заканчивать этот цырк

Я и не начинал никакого цирка. Вы спросили:
Gluk (Kazan)
А замыкания есть в Delphi ?

Я ответил, что нет, и попытался обосновать, почему нет.

Gluk (Kazan)
замыкания имеют весьма опосредованное отношение к "функциональному" стилю

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

Gluk (Kazan)
Пётр Седов
Это не к «C++-ный локальный функтор vs. Delphi-йская локальная процедура/функция», а просто к неудобству C++-ного локального функтора, безотносительно к другим языкам. Слишком ограниченный он

человек не должен критиковать другого человека на той почве, на которой он сам не стоит перпендикулярно

Если я считаю, что C++-ные локальные функторы -- неудобные и ограниченные, то, думаю, я имею право это высказать. И Delphi здесь совершенно ни при чём.

Gluk (Kazan)
В Delphi и таких то нет :)

Действительно, в Delphi нет локальных функторов, аналогичных C++-ным. Никто и не утверждал, что есть.

Gluk (Kazan)
в каой STL ты будешь передавать свои локальные функции ?

Delphi-йские локальные процедуры/функции не предназначены для того, чтобы их куда-то передавать (это запрещено). Они предназначены для непосредственного вызова.

Gluk (Kazan)
Пётр СедовНа C++ писать в функциональном стиле очень неудобно. Требуются 10-этажные шаблоны вроде Boost.Lambda. И компилируется это 2 часа.

да вы шо ? o O

Там есть замыкания или лямбда-функции? По-моему, использовать C++-шаблоны для мета-программирования в функциональном стиле -- это неудобно и нечитабельно (для большинства C++-программистов). К тому же, непонятно, как такую мета-программу отладить -- компилятор C++ не сообщает, что там у него внутри происходит.

Gluk (Kazan)
Пётр Седов
В C++ так же ручное управление памятью, поэтому удобных замыканий тоже не сделать.

Правда ?

Я слышал про планы добавить в C++0x (будущий стандарт C++) необязательную сборку мусора. Тогда удобные замыкания можно будет сделать, но это очень туманная перспектива.

Gluk (Kazan)
А вот в D собираются (хотя там аналогичная проблема)

В D нет аналогичной проблемы -- там автоматическое управление памятью (точнее, смешанное), в отличие от C++.

Gluk (Kazan)
дело очевидно не в "ручном" управлении памятью

Нет, чтобы реализовать удобные замыкания, требуется именно автоматическое управление памятью. Вы же сами написали:
Gluk (Kazan)
замыкания имеют весьма опосредованное отношение к "функциональному" стилю
К управлению памятью разумеется имеют самое прямое

2 Gluk (Kazan):

Gluk (Kazan)
1. Вы похвалились наличием в Delphi "удобных" локальных функций (которых нет в C++)

Я не похвалился, а заметил, что это удобно.

Gluk (Kazan)
2. Поскольку (с моей точки зрения) пользы от локальных функций не реализующих замыкания немного,

Польза от Delphi-йских локальных процедур/функций -- лёгкий доступ к контексту и лучшая структуризация кода. Если бы локальные функции были в C++, то пришлось бы меньше перекомпилировать: изменение внутренностей функции, написанной в .cpp-файле, не затрагивает заголовочный файл.

Gluk (Kazan)
я переспросил (разумеется зная ответ) как там у вас с замыканиями

Обычно, когда твёрдо знают ответ, вопрос не задают (Вы не преподаватель на экзамене и не часовой, спрашивающий пароль). К тому же, вопросов было два:
Gluk (Kazan)
А замыкания есть в Delphi ? Или на любой Чих будет AV ?

Второй вопрос заставляет усомниться, что Вы твёрдо знали ответ на первый.
Кстати, «у вас» -- это у кого?

Gluk (Kazan)
термин "ручное" управление несколько коробит (автоматических сторожей в C++ никто не отменял),

По моим понятиям, в C++ ручное управление памятью. Хотя его можно «полуавтоматизировать» с помощью разных ухищрений (например, умные указатели).

Gluk (Kazan)
4. Я несколько по другому понимаю слово "неотъемлемая".

Я в этом обсуждении не использовал слово «неотъемлемый» или его формы.

Gluk (Kazan)
Для меня оно означает не то что фича появилась в каком то месте, а скорее то, что место это без фичи просто не может существовать. Посему был приведен в пример Perl, ни разу не функциональный (об этом ниже), но реализующий вполне себе полноценные замыкания. Не удержусь от цитирования ображчика ущербной логики:

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

5. К слову сказать, даже в SICP макимальное внимание к замыканиям уделяется в разделах, посвещенных императивному программированию

Что является функциональным языком/программированием/стилем, а что не является -- это вопрос глубоко философский, мне его не интересно обсуждать. Мне интересно обсуждать, что на грешной земле делается -- C++-ные локальные функторы и Delphi-йские локальные процедуры/функции.

Gluk (Kazan)
6. Далее Вами было заявлено, что и Perl имеет отношение к ФП :) Конечно имеет, но C++ в таком случае, к ФП имеет еще большее отношение, поскольку из трех категорий языков

а) Языки поощеряющие ФП, но пригодные для ИП (Lisp)
б) Языки императивные на которых можно использовать ФП (Perl)
в) Языки на которых кроме как ФП больше никак писать нельзя (шаблоны C++, XSLT)

к ФЯ я все-таки отнесу последние

C++-шаблоны можно использовать как функциональный язык для мета-программирования, но у этого около-языка куча минусов:
* Большинство C++-программистов им не владеет.
* Невозможно пройтись по коду в отладчике.
* Не поддерживаются floating point числа.
* Очень неудобно указывать строковые литералы (и вообще работать со строками).

Gluk (Kazan)
7. Вами было заявлено, что ФП на C++ неудобно, громоздко и без boost-а чуть ли не невозможно (во всяком случае так я Вас понял),

Да, Вы правильно меня поняли. Для написания мета-программы в функциональном стиле, выполняющейся в compile-time, Boost не обязателен, C++-шаблонов достаточно. Boost нужен ради Boost.Lambda для написания программы в функциональном стиле, выполняющейся в run-time.

Gluk (Kazan)
на что Вам было предоставлено аргументированное ни разу не бустовое, не тривиальное и вполне быстро компилирующееся применение метапрограммирования на C++, совершенно однозначно имеющее отношение к ФП (в отличии от замыканий являющихся хоть и удобным но всего-лишь бантиком). Сложное ? на мой взгляд нет.

Да, сложное. В том смысле, что для большинства C++-программистов это тайнопись. Но главное: я имел в виду функциональный стиль в программах, выполняющихся в run-time, а не в compile-time.

Gluk (Kazan)
Просто несколько непривычное и требующее определенных навыков. Громоздкое ? сравним:
код на C++-шаблонах
код на Lisp-е
очевидно, что нет :)

Напишите на C++ в функциональном стиле преобразование недетерминированного конечного автомата в детерминированный, выполняющееся в run-time. Вот тут и проявится различие между C++ и функциональными языками. В отличие от мета-кода на C++-шаблонах, код на Lisp-е можно выполнить в run-time.

Gluk (Kazan)
8. Мной были упомянуты функторы как альтернатива локальным функциям и замыканиям (захват всего необходимого можно выполнять ручками в конструкторе).

Вот именно это и неудобно. С Delphi-йскими локальными процедурами/функциями не надо ничего захватывать вручную, всё просто и удобно.

Gluk (Kazan)
Разумеется, локальные функторы нельзя передавать в шаблоны :)

Именно о локальных функторах и идёт речь. И ещё о Delphi-йских локальных процедурах/функциях. То есть речь идёт о том, что определено локально (в рамках функции).

Gluk (Kazan)
но вложенные еще как можно ;)

О них речь не идёт.

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

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

И ещё та же проблема, что и с локальными функторами: тяжело дотянуться до контекста.

Gluk (Kazan)
Кстати, возможно я не до конца оценил глубину Вашей мысли:
авторИз-за отсутствия в C++ нормальных локальных функций (которым легко доступен контекст, например локальная переменная охватывающей функции), их приходится эмулировать, передавая указатель на контекст в обычную (нелокальную) функцию.
образчик кода на Delphi Вас не затруднит?

Код на C++ и Delphi -- см. ниже.

Gluk (Kazan)
В общем, пока что Вы не убедили меня что:
авторC++-ные локальные функторы -- менее удобная вещь, чем Delphi-йские локальные процедуры/функции, из которых легко использовать контекст (например, локальную переменную охватывающей процедуры/функции).
на мой взгляд, они куда более удобны и функциональны

В C++-ном локальном функторе тяжело дотянуться до контекста, это неудобно. В Delphi-йской локальной процедуре/функции легко дотянуться до контекста, это удобно.

Gluk (Kazan)
9. Вот это мне нравится:

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

С точки зрения логики, все вроде впорядке :) Зато можно подумать, что замыкания неотъемлимая часть ФП
И что не может быть ФП без замыканий (напоминает анекдот про бегимота, прилипшего к хвостику белочки)

Опять же, меня не интересует, в чём заключается глубинная истинная сущность функционального языка/программирования/стиля.

Gluk (Kazan)
авторНа C++ писать в функциональном стиле очень неудобно. Требуются 10-этажные шаблоны вроде Boost.Lambda. И компилируется это 2 часа.
IMHO надо добавлять.

Как ни странно, то, что я пишу, -- это моё личное мнение ( m y o pinion), за исключением цитат, выделенных особо.

Gluk (Kazan)
Ваше незнание или неумение не повод рожать (или поддерживать) нездоровые сенсации.

Нет никакой сенсации в том, что C++ плохо подходит для написания программ в функциональном стиле, выполняющихся в compile-time или run-time. Для этого другие языки есть.

Gluk (Kazan)
В том коде что я привел есть boost ?

В Вашем коде (преобразование недетерминированного конечного автомата в детерминированный, выполняющееся в compile-time) не используется Boost.

Gluk (Kazan)
10-этажные шаблоны ???

Нагромождение шаблонов есть.

Gluk (Kazan)
Или он компилировался у Вас 2 часа ?

Я не компилировал Ваш код.
Игрушечные примеры мета-программирования на C++-шаблонах (например, вычисление факториала) компилируются быстро. Но если делать что-то серьёзное, то компилируется долго.

Попробуйте сделать parser C++ с помощью Boost.Spirit. Уверен, компилироваться будет долго. Слышал, что люди отказываются от Boost.Python именно из-за времени компиляции.

Gluk (Kazan)
авторЭто не к «C++-ный локальный функтор vs. Delphi-йская локальная процедура/функция», а просто к неудобству C++-ного локального функтора, безотносительно к другим языкам. Слишком ограниченный он.
Примеры ограниченности, пожалуйста (желательно с C++ кодом)

1. Локальный функтор не может по-простому использовать контекст, например, локальную переменную охватывающей функции:
Доступ к контексту придётся делать через указатель (или ссылку):
Это неудобно (особенно, если контекста много). В Delphi таких проблем нет:

2. Тип локального функтора не может быть параметром шаблона (по крайней мере, в нынешнем C++), поэтому локальный функтор нельзя использовать, например, в качестве предиката для STL-алгоритма:
Выход -- сделать функторы нелокальными:
Но теряется локальность, и функторы надо упомянуть в заголовочном файле. Если захочется перейти от std::sort к собственному алгоритму сортировки (это разумно, если ключ -- целое число из небольшого диапазона), то придётся изменить содержимое заголовочного файла. Это вызовет избыточную перекомпиляцию.

Gluk (Kazan)
Только не локальных а вложенных

Не подменяйте тему, речь идёт именно о локальных функторах (то есть определённых в рамках функции):
Gluk (Kazan)
Пётр Седов
Локальные процедуры/функции -- это действительно удобно, и в VCL они широко используются, чтобы структурировать код.

Локальные функторы - это ТОЖЕ удобно :)

Хочется именно локальности, чтобы писать код «не отходя от кассы». И чтобы при изменениях перекомпилировать поменьше.

Gluk (Kazan)
авторDelphi-йские локальные процедуры/функции не предназначены для того, чтобы их куда-то передавать (это запрещено). Они предназначены для непосредственного вызова.
А функторы можно

Локальные функторы не передать в STL-алгоритм. Нелокальные -- можно, но речь не о них.

Gluk (Kazan)
И кто из них после этого ограниченный ???

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

Gluk (Kazan)
авторТам есть замыкания или лямбда-функции?
Вам нужны лямбды ? Их есть у нас:

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

Gluk (Kazan)
автор
По-моему, использовать C++-шаблоны для мета-программирования в функциональном стиле -- это неудобно и нечитабельно (для большинства C++-программистов). К тому же, непонятно, как такую мета-программу отладить -- компилятор C++ не сообщает, что там у него внутри происходит.

Неудобно, но единственно возможно.

C++-шаблоны -- не единственный способ мета-программирования, есть способ лучше: генерация кода (мета-программа пишет программу). Этот способ доступен для всех языков, в том числе для Delphi. Один из плюсов: мета-программу можно отладить.

Gluk (Kazan)
Кстати, Вы действительно думаете, что я написал все это без отладки ?

Каким образом отлаживать мета-программу на C++-шаблонах? По мета-коду на C++-шаблонах не пройтись в отладчике. Если внести неверное изменение, то сообщение компилятора об ошибке будет невнятным.

Gluk (Kazan)
Вы мне определенно льстите :)

Я не столько льщу Вам, сколько указываю на неудобство и непрактичность мета-программирования на C++-шаблонах.