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

ГВ>>Что даже не сильно удивляет. Длинные и многоярусные лямбды противоречат принципам реюзинга, "обычные" функторы могут быть предпочтительнее с этой точки зрения. Больше того, даже два использования какой-нибудь коротенькой лямбды типа "x >= SOMETHING_LOW && x <= SOMETHING_HIGH" уже побуждают сделать вместо неё обычную функцию или функтор, и обращаться к ним по собственному имени.

C>Это то о чем Вам говорил Влад. Лямбды С++ — неудобные недолямбды. Потому ими и не пользуются.

Дело не в удобстве, а в культуре программирования.

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

ГВ>>Добавим к проблемам развития C++ ещё то, что очень мало кто хочет столкнуться с необходимостью переписывать всё ранее разработанное ПО, чтобы оно компилировалось новыми компиляторами.

C>Компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников. Интересно, к чему бы это...

Я думаю, что это к тому, что компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников.

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

ГВ>>>Что даже не сильно удивляет. Длинные и многоярусные лямбды противоречат принципам реюзинга, "обычные" функторы могут быть предпочтительнее с этой точки зрения. Больше того, даже два использования какой-нибудь коротенькой лямбды типа "x >= SOMETHING_LOW && x <= SOMETHING_HIGH" уже побуждают сделать вместо неё обычную функцию или функтор, и обращаться к ним по собственному имени.

C>>Это то о чем Вам говорил Влад. Лямбды С++ — неудобные недолямбды. Потому ими и не пользуются.

ГВ>Дело не в удобстве, а в культуре программирования.

При чем тут "культура"? Вот в С# лямбды широко используются, не смотря на то, что язык, как и С++ императивный, а не функциональный. Просто потому, что там это УДОБНО.

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


ГВ>>>Добавим к проблемам развития C++ ещё то, что очень мало кто хочет столкнуться с необходимостью переписывать всё ранее разработанное ПО, чтобы оно компилировалось новыми компиляторами.

C>>Компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников. Интересно, к чему бы это...

ГВ>Я думаю, что это к тому, что компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников.

"ГВ>>Добавим к проблемам развития C++ ещё то, что очень мало кто хочет столкнуться с необходимостью переписывать всё ранее разработанное ПО, чтобы оно компилировалось новыми компиляторами."

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

S>>Разве возвращается не обертка над объектом на стеке?

ГВ>Нет, это не обёртка над стеком: m_f, m_dx — собственные члены объекта.
догадался

S>>Копирования я тут не вижу.

ГВ>1. В конструкторе: "m_f(f), m_dx(dx)" — это копирования аргумента и указателя на функцию.
ГВ>2. Неявно сгенерированный конструктор копирования: LambdaFunctor(const LambdaFunctor &). Если какая-то функция вернёт LambdaFunctor (например, как делает derivative: return LambdaFunctor(f, dx)), то вызван будет как раз этот конструктор копирования.
Ок, функция возвращает копию. Но вызывающая сторона принимает function<double(double)>. Что это? Я подумал, что это "Polymorphous wrapper for function object". Но я не знаю физики этого понятия. Какое отношение тип function<double(double)> имеет к возвращаемой копии экземпляра LambdaFunctor?

S>>А даже если бы оно было, разве обертка управляет временем жизни того, что она обертывает?
ГВ>Повторюсь, это не обёртка.
Точно?

S>>Кстати, эта обертка — аналог boost-овской?

ГВ>Скорее, это обычный функтор. boost-овые лямбды сильно посложнее.
функтор — это экземпляр объекта. Экземпляр может быть таким или этаким, когда принимающая сторона знает каким он будет — тут все поянтно, т.к. на стеке выделится память под экземпляр. А что есть function<double(double)>.

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

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

ГВ>>[...] но это главным образом определяет отличия динамики развития C++ от Java, C# и иже с ними.
C>Да, это не плохо, что язык застрял на мертвой точке и вот уже больше 10 лет сдвинуться с нее не может. Это просто замечательно.

ИМХО, это real world и ничего больше. И потом, как видишь, ничего он не застрял. Что за манера называть синее зелёным?

ГВ>>Так что, как бы там что-то во что-то ни перерастало, и какими бы метафизическими свойствами C++ ни наделялся, но он как раз является плодом объёмного договорного процесса очень разных разработчиков программного обеспечения. "Какой-то там" стандарт можно принимать хоть по десять раз на дню, а такой, что удовлетворит кучу разных участников и принимается не для проформы, вырабатывать, всё же, посложнее. 10-12 лет для таких взаимодействий — не то, что мелочь, а так, цветочек понюхать не успеешь.

C>Ой, ну может хватит чушь молоть-то? 10-12 лет это МОРЕ времени. Посмотрите на С# и Nemerle, которых 12 лет тому назад еще и в планах не было.

Скажем так, я изложил свои соображения, почему считаю, что в данном случае 10-12 лет — не так уж и долго, как может показаться на первый взгляд. Не буду спорить с тем, что на первый взгляд 10-12 лет — это уйма времени. C# и Nemerle в данном случае не уместный пример, поскольку у этих языков есть владелец, Главные Разработчики и т.п. Стандарта ANSI, насколько я знаю, ни на тот ни на другой — нет (вот только про ECMA в данном контексте упоминать не стоит, это не смешно).

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

C>>>Компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников. Интересно, к чему бы это...
ГВ>>Я думаю, что это к тому, что компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников.
C>"ГВ>>Добавим к проблемам развития C++ ещё то, что очень мало кто хочет столкнуться с необходимостью переписывать всё ранее разработанное ПО, чтобы оно компилировалось новыми компиляторами."

И при чём здесь C#?

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

ГВ>>>>Что даже не сильно удивляет. Длинные и многоярусные лямбды противоречат принципам реюзинга, "обычные" функторы могут быть предпочтительнее с этой точки зрения. Больше того, даже два использования какой-нибудь коротенькой лямбды типа "x >= SOMETHING_LOW && x <= SOMETHING_HIGH" уже побуждают сделать вместо неё обычную функцию или функтор, и обращаться к ним по собственному имени.

C>>>Это то о чем Вам говорил Влад. Лямбды С++ — неудобные недолямбды. Потому ими и не пользуются.
ГВ>>Дело не в удобстве, а в культуре программирования.
C>При чем тут "культура"? Вот в С# лямбды широко используются, не смотря на то, что язык, как и С++ императивный, а не функциональный. Просто потому, что там это УДОБНО.

Ну ё-моё, ты хоть прочти то, чему возражаешь:

Больше того, даже два использования какой-нибудь коротенькой лямбды типа "x >= SOMETHING_LOW && x <= SOMETHING_HIGH" уже побуждают сделать вместо неё обычную функцию или функтор, и обращаться к ним по собственному имени.

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

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

S>Ок, функция возвращает копию. Но вызывающая сторона принимает function<double(double)>. Что это? Я подумал, что это "Polymorphous wrapper for function object". Но я не знаю физики этого понятия.

См. ниже.

S>Какое отношение тип function<double(double)> имеет к возвращаемой копии экземпляра LambdaFunctor?

М-м-м... Да, приведение типов я прозевал. function<double(double)> (теоретически) может ссылаться на экземпляр LambdaFunctor и вызывать LambdaFunctor::operator()(double). Правда для этого вполне может понадобиться разместить экземпляр LambdaFunctor в динамической памяти с подсчётом ссылок, управлением и всей свитой.

S>>>А даже если бы оно было, разве обертка управляет временем жизни того, что она обертывает?
ГВ>>Повторюсь, это не обёртка.
S>Точно?

Ну а что она оборачивает? Разве что вызов f через оператор.

S>>>Кстати, эта обертка — аналог boost-овской?
ГВ>>Скорее, это обычный функтор. boost-овые лямбды сильно посложнее.
S>функтор — это экземпляр объекта. Экземпляр может быть таким или этаким, когда принимающая сторона знает каким он будет — тут все поянтно, т.к. на стеке выделится память под экземпляр. А что есть function<double(double)>.

По-простому — это шаблон, инстанцированный типом double(double), сиречь — сигнатурой функции double func(double). В бусте это — довольно хитрый шаблон, там есть собственный менеджер, shared_ptr-ы, динамическая память... До фига всего. Мне интересно, как это реализовали в C++0x. Заморочка понятна: если по сигнатуре мы ещё можем точно вычислить размер памяти, необходимый для хранения параметров и соответственно их скопировать, то когда появляются ещё и локальные переменные, всё становится намного интереснее. Либо динамическая память, либо ещё какой-то механизм неявного "дораспределения" памяти для таких переменных.

S>З.Ы. Извиняюсь за нубские вопросы, с C++ не имел дела с выхода шарпа. В поиске нашел только вот это.

Что касается C++0x, то на данный момент я точно такой же нуб. Я ж говорю, что живого компилятора ещё в руках не держал.

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

C>>>>Компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников. Интересно, к чему бы это...
ГВ>>>Я думаю, что это к тому, что компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников.
C>>"ГВ>>Добавим к проблемам развития C++ ещё то, что очень мало кто хочет столкнуться с необходимостью переписывать всё ранее разработанное ПО, чтобы оно компилировалось новыми компиляторами."

ГВ>И при чём здесь C#?

С# пример того, что можно очень активно развивать язык, сохраняя "обратную совместимость" на уровне компилятора.

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

C>>>>>Компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников. Интересно, к чему бы это...
ГВ>>>>Я думаю, что это к тому, что компилятор С# 3.0 прекрасно справляется со сборкой С# 1 исходников.
C>>>"ГВ>>Добавим к проблемам развития C++ ещё то, что очень мало кто хочет столкнуться с необходимостью переписывать всё ранее разработанное ПО, чтобы оно компилировалось новыми компиляторами."
ГВ>>И при чём здесь C#?
C>С# пример того, что можно очень активно развивать язык, сохраняя "обратную совместимость" на уровне компилятора.

А кто спорит с тем, что это можно? Я только констатирую возможные соображения, которые влияют на развитие C++.

С другой стороны, в период 2000-2003 был вполне себе ощутимый конфликт между возможностями Intel C++ и MSVC++. Собственно, разнобой в возможностях компиляторов вполне сохранился и по сей день (в том же бусте куча кода посвящена как раз этому разнобою). Хотя да, можно сохранять совместимость, а вот тем не менее.

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

VD>>Ага. Причем юмор начинается со слов "лямбды в с++" ибо на сегодня в С++ нет даже тех недолямбд которые описаны в С++ох (читать как си-плюс-плюс ох).
CC>Ну в С++0х они есть. Компилеры с лямбдами тоже есть (ICC).
CC>Удивительно, но из всего что появилось в ICC из С++0х применения в живых проектах не нашли только лямбды.

Для особо одаренных повторяю. Нет никакого С++0х. С++0х — это рабочее название черновика.

А в "кампилирах" есть еще свойства и поддержка COM. И что с того?

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

VD>Для особо одаренных повторяю. Нет никакого С++0х. С++0х — это рабочее название черновика.

Хорошо, C++0x в данном контексте — это эвфемизм для "C++ Standard Draft Which Is Close To Approve By The Appropriate Standard Commitee".

VD>А в "кампилирах" есть еще свойства и поддержка COM. И что с того?

В компиляторах много чего есть, но не всё из этого планируется к принятию в виде стандарта.

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

VD>>А в "кампилирах" есть еще свойства и поддержка COM. И что с того?

ГВ>В компиляторах много чего есть, но не всё из этого планируется к принятию в виде стандарта.

Оно уже 11 лет планируется. Так что говорить о чем-то будет можно только когда стандарт выйдет. О чем я и говорил.

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

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

ГВ>>>Обычно он делается по-разному, это раз. Баги согласования жизненных циклов ловятся не труднее, чем любые другие — это два.

G>>Ну как например?

ГВ>Есть ещё совсем ничего не подсчитывающий auto_ptr. Как минимум.

Семантика владения в лямбде никак не подойдет. Еще варианты есть?
Может всетаки уже стоит признать что в С++ в обозримом будущем не будет нормальных лямбд.

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

VD>>>А в "кампилирах" есть еще свойства и поддержка COM. И что с того?
ГВ>>В компиляторах много чего есть, но не всё из этого планируется к принятию в виде стандарта.
VD>Оно уже 11 лет планируется. Так что говорить о чем-то будет можно только когда стандарт выйдет. О чем я и говорил.

Отнюдь. Даже если в окончательную версию стандарта лямбды не войдут (что выглядит фантастично), их из компиляторов никто убирать не будет (это выглядит ещё более фантастичным). Поэтому с формальной точки зрения ты прав — стандарта ещё нет, и казалось бы, обсуждать нечего, но коль скоро на практике фичи в компиляторах уже есть (больше того, описание фич прямо ссылается на драфт стандарта), следовательно, утверждать, что их нет — абсурд. И следовательно, нам вполне есть, что обсуждать.

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

ГВ>>Есть ещё совсем ничего не подсчитывающий auto_ptr. Как минимум.
G>Семантика владения в лямбде никак не подойдет. Еще варианты есть?

Почему не подойдёт? Как по мне, так вполне подойдёт.

G>Может всетаки уже стоит признать что в С++ в обозримом будущем не будет нормальных лямбд.

Знаешь, это очень сильное колдунство — признавать отсутствие наличествующего. "Видишь суслика? А его нет!"

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

ГВ>Отнюдь. Даже если в окончательную версию стандарта лямбды не войдут (что выглядит фантастично), их из компиляторов никто убирать не будет

Еще как будут, как убирали несоответствия с 98-ым стандартом.

ГВ>Поэтому с формальной точки зрения ты прав — стандарта ещё нет, и казалось бы, обсуждать нечего, но коль скоро на практике фичи в компиляторах уже есть (больше того, описание фич прямо ссылается на драфт стандарта), следовательно, утверждать, что их нет — абсурд. И следовательно, нам вполне есть, что обсуждать.

Никаких расширений пока нет. Речь идет о бэтах которые не зарелизятся до 2010 года.

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

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

ГВ>>Отнюдь. Даже если в окончательную версию стандарта лямбды не войдут (что выглядит фантастично), их из компиляторов никто убирать не будет
VD>Еще как будут, как убирали несоответствия с 98-ым стандартом.

Маловероятно. И первое, и второе. Гораздо более вероятно, что как и с 98-м стандартом, начнётся вакханалия, как это было во времена VC6 — сколько компиляторов, столько реализаций шаблонов. Здесь будут другие заморочки.

ГВ>>Поэтому с формальной точки зрения ты прав — стандарта ещё нет, и казалось бы, обсуждать нечего, но коль скоро на практике фичи в компиляторах уже есть (больше того, описание фич прямо ссылается на драфт стандарта), следовательно, утверждать, что их нет — абсурд. И следовательно, нам вполне есть, что обсуждать.

VD>Никаких расширений пока нет. Речь идет о бэтах которые не зарелизятся до 2010 года.

Ну и что? Значит эти расширения пока в бетах. Факт их существования не отменяется.

VD>Мне кажется, что включение фич из черновика стандарта является своеобразным протестом против глупого затягивания его принятия и способом подтолкнуть его принятие хоть в каком-то виде, потому как комитет давно живет ради собственного развлечения.

Да не так всё просто, судя по всему. Где-то пробегало, что это составляющая процедуры принятия стандарта — разработчики компиляторов получают некоторый запас времени для предварительной реализации фич. Есть ещё и сугубо ISO-шные процедуры принятия стандарта, которые, как я понимаю, должны пройти после того, как окончательный драфт стандарта будет одобрен комитетом. В общем, в этой бюрократии я не силён, но похоже, что твои высказывания о "протесте против затягивания" и "ради собственного развлечения" не совсем отражают действительность.

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

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

ГВ>>>Есть ещё совсем ничего не подсчитывающий auto_ptr. Как минимум.
G>>Семантика владения в лямбде никак не подойдет. Еще варианты есть?
ГВ>Почему не подойдёт? Как по мне, так вполне подойдёт.


G>>Может всетаки уже стоит признать что в С++ в обозримом будущем не будет нормальных лямбд.
ГВ>Знаешь, это очень сильное колдунство — признавать отсутствие наличествующего. "Видишь суслика? А его нет!"
Точно, ты ведь до сих пор не признаешь что нету и не будет в С++ нормальных лямбд, а в других языках есть.