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

E>>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.
Z>Конкретные проблемы уже обсуждали, и адекватные ответы вы получили.

Кхе... Давно это было, не помню уже, что за ответы я получал. Может ссылочки подскажите?

E>>О том, как бы мне хотелось видеть lambda в C++ я писал: здесь

Автор: eao197
Дата: 11.10.05

, здесь

Автор: eao197
Дата: 11.10.05

, здесь

Автор: eao197
Дата: 11.10.05

и здесь

Автор: eao197
Дата: 11.10.05

. Только для этого нужна поддержка на уровне компилятора, а не библиотек.
Z>Чем хуже поддержка на уровне библиотек?

Не знаю, зачем поднимать этот вопрос в очередной раз. Но, есть языки, в которых поддержка lambda сделана на уровне языка. Посмотрите, например, на блоки кода в Ruby и Smalltalk, на Scala, на Nemerle (не говоря уже про Lisp и сонмище функциональных языков). Использование lambda в них -- это вполне естественный и удобный процесс. К которому быстро привыкаешь.

После такого опыта хочется иметь в C++ нормальную реализацию, нормальную. А не имеющиеся сейчас костыли. Просто хочется. Просто потому, что уже привык к хорошему.

Z>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.

Да ради бога. Мне еще ни разу не пришлось использовать списки типов. А вот функторы с STL-левскими алгоритмами постоянно. И тянуть в проект boost::lambda для того, чтобы получить жалкую кальку с нормальной лябды не хочется.

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

E>Кхе... Давно это было, не помню уже, что за ответы я получал. Может ссылочки подскажите?
Трэд выше пролистайте

Z>>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.
А вы посмотрите его реализации абстрактной фабрики и паттерна визитор. И все станет на свои места. После этого кажется что остальные все реализации фабрик ( как на С++, так и в других языках ) — костыли.

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

VD>Ну, а теперь подытоживаем... Мы получили такой же дизайнер как в C# с мааааленькими оговорочками.

имхо обратно. это дизайнер C# получился такой же, но с оговорочками.

VD>Ну, и чем вы тут хвастались? Убогостью? Ее и так кругом хватает.

это вопрос с создателям "нового"... уж никак не к tcl/tk имхо.

zabivator wrote:
> Z>>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.
> А вы посмотрите его реализации абстрактной фабрики и паттерна визитор. И все станет на свои места. После этого кажется что остальные все реализации фабрик ( как на С++, так и в других языках ) — костыли.
Восхищение Александреску -это нормально. Как и последующее разочарование
и трезвая оценка границ C++. Не беспокойтесь за ув. eao197, у него уже и
так все на местах .

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

E>>Кхе... Давно это было, не помню уже, что за ответы я получал. Может ссылочки подскажите?
Z>Трэд выше пролистайте

Полистал, адекватных ответов по поводу именно лямбды не увидел. Покажите ссылкой, если не сложно.
Зато нашел несколько собственных фраз: "Лямбды так же нужны не всем" и "И еще не факт, что лямбды на самом деле так удобны, как об этом говорят" которые выглядят излишне категоричными. Думаю, нужно из пояснить.

Итак, лябмды в Ruby очень удобны, когда нужно обработать какую-то коллекцию элементов. Например, написать выражение вида:

items.inject( {} ) { bla-bla-bla }.sort { bla-bla-bla }.collect { bla-bla-bla }.each { bla-bla-bla }

Очень удобно. Так же удобно параметризовать какую-то операцию лямбдой:

def do_import( params, inserter )
  ... inserter.call( data ) ...
end

def initiate_import( params )
  inserter = if params.dry_run # реального импорта быть не должно
      lambda { puts "inserting " + ... }
    else
      # Для реального импорта используем SQL.
      lambda { dbh.execute "INSERT INTO ..." }
    end
  do_import( params, inserter )
end

Но, зачастую лябмды сильно разрастаются в размерах и код становится сложным для понимания. Причем не так уж редко оказывается, что если бы с самого начала вместо лямбды было использовано другое решение (например, объектная декомпозиция), то развитие кода было бы проще (как, например, в случае с показанным мной inserter-ом). Именно поэтому я считаю, что лямбдой очень легко злоупотребить. И не так уж часто она нужна на самом деле.

Но все это хорошо в managed языках со сборкой мусора. В них, например, если мы перемещаем объекты между несколькими коллекциями в серии inject/sort/collect мы, по крайней мере, уверены, что они не станут мусором. Поэтому легко из lambda возвратить какое-то значение, сохранить его и использовать дальше. Так же, лямбды используют (если не путаюсь в терминах) лексическое замыкание, т.е. сохраняют возможность доступа к переменным в той области видимости, в которой определена lambda. И опять же благодоря сборке мусора мы не заботимся о том, что эти ссылки станут невалидными.

В C++ иная ситуация, сборки мусора нет. Из-за этого нужно проявлять осторожность при возврате лямбды из какого-то контекста. Что уже снижает удобство использования. Так же в C++ не просто организовать цепочки inject/sort/collect. Это связано как с организацией стандартных контейнеров и алгоритмов, так и с отсутствием сборки мусора. Например, если в результате сортировки у меня получается временный объек-контейнер из которого мне нужно взять указатель на один из элементов. Время действия этого указателя будет гораздо меньше, чем в языке со сборкой мусора. Поэтому я считаю, что ценность лямбды в C++ (даже если она будет сделана на уровне языка, но без сборки мусора) ниже, чем тех же делегатов в C# или в D.

И еще одно замечание. Имхо, C++ не сильно подходит для программирование в функциональном стиле. Все эти std::for_each, std::accumulate, std::find_if -- это конечно хорошо и часто они улучшают читабельность кода. Но, имхо, все-таки выглядят бледной тенью аналогов из языков, в которых функциональный стиль поддерживается более естественным образом. Кроме того, сейчас, когда managed языки (в первую очередь Java и C#, а так же Smalltalk, и функциональные языки, вроде OCaml) благодоря достижениям в области JIT-а и агресивной оптимизации показывают очень высокую производительность, но при этом делают разработку более комфортной (за счет сборки мусора и типобезопасности), главная ниша C++ -- это высокопроизводительные и нересурсоемкие приложения. И вот здесь оказывается, что писать на C++ быстрые программы в стиле "C with classes" с разумным использованием шаблонов гораздо проще, чем нагромождая подобие функционального стиля из алгоритмов и функторов. В частности, проще затем оптимизировать, когда весь код как на ладони и не нужно погружаться в дебри деталей работы сложных шаблонных конструкций.

Z>>>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.
Z>А вы посмотрите его реализации абстрактной фабрики и паттерна визитор. И все станет на свои места. После этого кажется что остальные все реализации фабрик ( как на С++, так и в других языках ) — костыли.

Интересно, а с какими языками вы сравнивали решение Александреску?
Мне, например, нравится реализация фабрики в Ruby:

def factory klass, *args
    klass.new *args
end

class A
    def hello
        "#{self.class.name}: hello"
    end
end

class B
    def initialize greeting
        @greeting = greeting
    end

    def hello
        "#{self.class.name}: #{@greeting}"
    end
end

class C
    def initialize greeting, a, b
        @greeting = greeting
        @a = a
        @b = b
    end

    def hello
        "#{self.class.name}: #{@greeting}, and: #{@a.hello} and #{@b.hello}"
    end
end

objs = [
    factory( A ),
    factory( B, 'have a nice day' ),
    factory( C, 'kill yourself!', factory( B, 'good morning' ), factory( A ) )
]

objs.each { |o| puts o.hello }

В результате получаем:

A: hello
B: have a nice day
C: kill yourself!, and: B: good morning and A: hello

Довольно просто и симпатично, не находите?

---

Можно ли узнать, зачем вы подняли это обсуждение и, в частности, завели разговор про лямбды в C++?

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

E>>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.
Z>Конкретные проблемы уже обсуждали, и адекватные ответы вы получили.

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

E>>О том, как бы мне хотелось видеть lambda в C++ я писал: здесь

Автор: eao197
Дата: 11.10.05

, здесь

Автор: eao197
Дата: 11.10.05

, здесь

Автор: eao197
Дата: 11.10.05

и здесь

Автор: eao197
Дата: 11.10.05

. Только для этого нужна поддержка на уровне компилятора, а не библиотек.
Z>Чем хуже поддержка на уровне библиотек?
Z>Если вспомнить, например, про списки типов Александреску, так можно сказать, что никто в С++ и в кошмарах не закладывал такой функциональност, но тем не менее, она была реализована только средствами языка.

Лет 10 назад была какая-то такая передача на ТВ и в ней рубрика "очумелые ручки". Там людей учили делать цветочные горшки из виниловых лонгплеев.
Между прочим, изобретатели LP в свое детище такой функциональности не закладывали.
И что Вы думаете? Наведываясь в гости к друзьям и знакомым я стал с удивлением обнаруживать забавные но странные цветочные горшки. К счастью, через некоторое время увлечение прошло, как пройдет, наверное, и мода на наколеночное изготовление лямбд в C++.
Туда ей и дорога!
Мало того, что базовое средство языка (что-то более базовое, чем лямбда лично мне придумать очень сложно) реализовывать в библиотеке немного не логично, да и сделать нормальные замыкания без GC едва ли возможно.

Suum cuique, господа.

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

E>>>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.
Z>>Конкретные проблемы уже обсуждали, и адекватные ответы вы получили.

K>Это, кстати, захватывающее чтение и очень показательное. Лично я на этих форумах ничего хуже про C++ не читал. Причем эффект усиливается тем, что все трое участников дискуссии большие любители C++ а не пропагандисты из вражеского лагеря.

Это кто?

eao197,

E>Но, зачастую лябмды сильно разрастаются в размерах и код становится сложным для понимания.

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

E>Интересно, а с какими языками вы сравнивали решение Александреску?
E>Мне, например, нравится реализация фабрики в Ruby:

E>def factory klass, *args
E>    klass.new *args
E>end
...
E>objs = [
E>    factory( A ),
E>    factory( B, 'have a nice day' ),
E>    factory( C, 'kill yourself!', factory( B, 'good morning' ), factory( A ) )
E>]

E>objs.each { |o| puts o.hello }

Ммм, красота! А вот так вот можно:

objs = 
{[
    a = factory(A),
    b = factory(B, 'have a nice day'),
    c = factory( 'kill yourself!', b, a)
]}

?
(Я обернул список лямбдой, чтобы переменные a, b и c снаружи были не видны.)

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

K>>Это, кстати, захватывающее чтение и очень показательное. Лично я на этих форумах ничего хуже про C++ не читал. Причем эффект усиливается тем, что все трое участников дискуссии большие любители C++ а не пропагандисты из вражеского лагеря.
E>Это кто?

Это Вы, alexeiz, Cyberax

Имеется в виду обсуждение, начинающееся отсюда

Автор: alexeiz
Дата: 11.10.05

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

K>>>Это, кстати, захватывающее чтение и очень показательное. Лично я на этих форумах ничего хуже про C++ не читал. Причем эффект усиливается тем, что все трое участников дискуссии большие любители C++ а не пропагандисты из вражеского лагеря.
E>>Это кто?

K>Это Вы, alexeiz, Cyberax

K>Имеется в виду обсуждение, начинающееся отсюда

Автор: alexeiz
Дата: 11.10.05

А, я-то думал, что вы про обсуждение в "Tcl как обоснование..." (придумали ж тему, однако).
Только почему же у вас сложилось мнение, что хуже про C++ больше нигде не говорили?
Имхо, нормально пообсуждали то, чего в C++ нет.

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

K>>>>Это, кстати, захватывающее чтение и очень показательное. Лично я на этих форумах ничего хуже про C++ не читал. Причем эффект усиливается тем, что все трое участников дискуссии большие любители C++ а не пропагандисты из вражеского лагеря.
E>>>Это кто?
K>>Это Вы, alexeiz, Cyberax
K>>Имеется в виду обсуждение, начинающееся отсюда

Автор: alexeiz
Дата: 11.10.05

E>Только почему же у вас сложилось мнение, что хуже про C++ больше нигде не говорили?

Может и говорили, но я не читал.

E>Имхо, нормально пообсуждали то, чего в C++ нет.

Так не в том проблема, что чего-то где-то нет. В данном случае проблема с тем, что есть.
А есть такой мегарулез как boost, который делает C++ современным, высокоуровневым и выразительным.
Читаю я, допустим такие слова:

Право слово, доисторический код какой-то. Так уже никто не пишет.

И что я должен ждать? Наверное что-то модерновое, прогрессивное. Клеймит, понимаете ли, автор пещерный стиль, а потом выдает вот такое:

int a[] = {1, 2, 3, 2, 4, 5, 7, 6, 7, 2};
typedef map<int, int> map_t;
typedef map_t::value_type val_t;
map_t occur;

for_each(begin(a), end(a),
        if_(_1 < 7) [ bind(&map_t::operator[], &occur, _1)++ ]);

for_each(begin(occur), end(occur),
        cout << bind(&val_t::first, _1) << ":" << bind(&val_t::second, _1) << "\n");

Красотища-то какая! Вот это, значит то, что в этом сезоне comme il faut? На это надо ровняться?
Увольте.
Тут бы самое время посмеяться — но как-то даже и не удобно. Горе ведь у человека. Пусть даже он об этом и не подозревает.
Если это будущее C++, то оно, право, какое-то гм... мрачноватое что-ли. Как минимум безрадосное.
Я никого запинывать не хочу, у C++ есть своя область применения, но когда дело доходит до таких вот вещей он бледнеет и держится за стенку. Любому, кто видел более элегантные решения претензии С++ + boost на сверхвысокоуровневость и ФП кажутся не то, чтобы очень обоснованными. Но Вам-то я думаю эту позицию нет нужды пояснять.

АХ>Ну а вообще в этой области (number crunching) начинают рулить шейдеры : ( здесь )
АХ>и соответственно такие языки как Cg, DirectX HLSL и GLSL.

BrookGPU рекомендую.

Шейдеры ОЧЕНЬ ограничены. Например, они не умеют делать scatter (помещение результата в нужное место). Обратная операция gather — забор элемента из нужного места.

Brook (kernel-stream based computation) это шаг вперед, но очень маленький.

Вообще, все успешные попытки распараллеливания с изменением фон-неймановскому стилю отказываются либо от scatter (GPU), либо от gather (есть тут такие).

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

E>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.

За подобные слова несколько лет назад меня здесь закидали какашками. Все же прогрес не стоит на месте.

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

E>>После работы на языке, где есть нормальная, полноценная lambda, от наворотов типа boost::lambda хочется держаться подальше.

VD>За подобные слова несколько лет назад меня здесь закидали какашками. Все же прогрес не стоит на месте.

Во-первых, вряд ли я принимал участие в этом процессе.
Во-вторых, boost::lambda мне вообще никогда не нравился, даже когда я еще на Ruby не программировал.
В-третьих, те, кто кидался в тебя за такие слова тогда, вероятно, повторят это и сейча. А заодно и в меня