Здравствуйте, Sinclair, Вы писали:
ГВ>> C++ предполагает три различных способа передачи параметров: значение, ссылка, указатель. "Нормальные" замыкания, судя по твоему высказыванию — это только ссылка, контролируемая GC.
S>Нет, это "только ссылка". Потому что семантика передачи ссылки принципиально отличается от передачи по значению, и именно она нужна. GC — второстепенная деталь реализации, без которой всё вместе трудно заставить работать.
спасибо, Капитан, за ликбез про семантику, а "мужики то не знали". Только с чего ты взял что нужна именно она? С++ предоставляет вариант — замыкать контекст по ссылке или по значению (кстати некотороые из lisp'ов таки замыкания реализуют через копирование, ага). Очевидно ето плюс, т.к. программист не ограничен "единственно правильным решением".

ГВ>> Я не хочу сказать, что такая точка зрения не имеет права на существование, но это никак не противоречит копированиям и прочим тра-ля-ля.
S>Геннадий, не надо придуриваться. Есть общепринятая трактовка замыкания, в которой замыкается полный лексический контекст. И плюсы не в состоянии обеспечить реализацию этой трактовки. А говорить "вот мы изобрели некоторое малополезное подмножество вашей функциональности, и назвали его точно так же, как полное — вот вам и замыкания" — это нечестно.
не надо выдумывать, в новом с++ именно замыкание, аргументов против так и не увидел, разве отсутствует "замыкание на полный лексический контекст", али что?

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

VD>>Нет таких ссылок и быть не может. Потому как это бред. Стоимость вызова микроспопически мала. Ее можно заметить на вызове методов-пустышек в цикле. А их то как раз отлично оптимизирует (инлайнит) JIT.

ГВ>Судя по всему, не всё JIT оптимизирует и не всегда.

Вам не надоело кидаться какашками? Вроде никто не утверждал, что управляемые языки есть серебрянной пулей, но они дают разумный компромис и с учетом того, что компьютерное время все более и более дешево в сравнении с человеко-часами, затрачиваемыми на разработку, будущее — однозначно за управляемыми языками. Более того, я уверен, что нам предстоит еще увидеть полностью управляемые ОС типа Singularity.

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

VD>>Это махровое ламерство. Собственно данная беседа для меня потеряла всяческий интерес.

COF>Для меня эта беседа потеряла интерес когда я покрутил приложение, которое (по словам одного из обвинителей меня в ламерстве) якобы летает. Оказалось, что мало того, что оно тормозит, так еще и память утекает, причем со свистом — так, что средней C++-ной программе надо постараться такую утечку организовать. В общем, гладко было на бумаге, да забыли про овраги — практика пока теорию не подтверждает. Лепите уважаемые свои лямбды дальше

Камень в мой огород? Оно действительно летает и не тормозит. В версии 0.9.5 В RC явно что-то перемудрили. Почти наверняка проблема там в анменеджед модулях — например, во флэщ проигрывателе, который активно используется. Впрочем, не берусь утверждать.

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

ГВ>>Судя по всему, не всё JIT оптимизирует и не всегда.

C>Вам не надоело кидаться какашками?

Хм. Уж, по-моему, если у кого резьбу и срывает, то это у хулителей C++. Тебе цитаты привести или сам найдёшь? И вообще говоря, называть рекомендации Microsoft "какашками" — это сильно, да. Учту, что ссылка на MSDN может быть приравнена к хулению.

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

Отлично, очень рад. Кто-то утверждал обратное (обратное "разумному компромиссу", а не "будущему за...", разумеется)?

C>Более того, я уверен, что нам предстоит еще увидеть полностью управляемые ОС типа Singularity.

Ну и отлично ещё раз, возьми с полки пирожок. Думаешь, я собираюсь спорить с твоей уверенностью?

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

Продолжим общение, когда Вы смените хамский тон на нечто более цивилизованное.

ГВ>Хм. Уж, по-моему, если у кого резьбу и срывает, то это у хулителей C++. Тебе цитаты привести или сам найдёшь? И вообще говоря, называть рекомендации Microsoft "какашками" — это сильно, да. Учту, что ссылка на MSDN может быть приравнена к хулению.
ГВ>Отлично, очень рад. Кто-то утверждал обратное (обратное "разумному компромиссу", а не "будущему за...", разумеется)?
ГВ>Ну и отлично ещё раз, возьми с полки пирожок. Думаешь, я собираюсь спорить с твоей уверенностью?

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

C>Продолжим общение, когда Вы смените хамский тон на нечто более цивилизованное.

Боюсь, что это не возможно, поскольку мой "хамский тон" существует, преимущественно, в твоём воображении.

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

S>Да, мы в курсе, что C++0x должен содержать все нужные возможности по определению.

Посмотри сюда, думаю, тебе будет интересно.

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

Х>Здравствуйте, Sinclair, Вы писали:
ГВ>>> C++ предполагает три различных способа передачи параметров: значение, ссылка, указатель. "Нормальные" замыкания, судя по твоему высказыванию — это только ссылка, контролируемая GC.
S>>Нет, это "только ссылка". Потому что семантика передачи ссылки принципиально отличается от передачи по значению, и именно она нужна. GC — второстепенная деталь реализации, без которой всё вместе трудно заставить работать.
Х>спасибо, Капитан, за ликбез про семантику, а "мужики то не знали". Только с чего ты взял что нужна именно она? С++ предоставляет вариант — замыкать контекст по ссылке или по значению (кстати некотороые из lisp'ов таки замыкания реализуют через копирование, ага). Очевидно ето плюс, т.к. программист не ограничен "единственно правильным решением".
Ага, он ограничен двумя неправильными, и одним неочевидным и частично правильным.
Кроме того полноценные замыкания, которые продлевают жизнь контекста, невозвожны без GC.
Куча способов сделать неправльно — плохая черта для языка.

ГВ>>> Я не хочу сказать, что такая точка зрения не имеет права на существование, но это никак не противоречит копированиям и прочим тра-ля-ля.
S>>Геннадий, не надо придуриваться. Есть общепринятая трактовка замыкания, в которой замыкается полный лексический контекст. И плюсы не в состоянии обеспечить реализацию этой трактовки. А говорить "вот мы изобрели некоторое малополезное подмножество вашей функциональности, и назвали его точно так же, как полное — вот вам и замыкания" — это нечестно.
Х>не надо выдумывать, в новом с++ именно замыкание, аргументов против так и не увидел, разве отсутствует "замыкание на полный лексический контекст", али что?

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

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

G>"замыкание на полный лексический контекст" и есть то самое замыкание с которого начался разговор. То что может быть когда-нибудь будет в новом стандарте С++ замыканием не станет.

Напротив. Это как раз полное классическое замыкание с некоторой спецификой, свойственной C++ (явное разделение ссылок и значений, const/mutable, далее по тексту). То, что лямбда не навязывает обязательной модификации жизненного цикла контекста — есть хорошо, и хорошо весьма.

Я имел в виду Part 1.

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

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

G>>"замыкание на полный лексический контекст" и есть то самое замыкание с которого начался разговор. То что может быть когда-нибудь будет в новом стандарте С++ замыканием не станет.

ГВ>Напротив. Это как раз полное классическое замыкание с некоторой спецификой, свойственной C++ (явное разделение ссылок и значений, const/mutable, далее по тексту). То, что лямбда не навязывает обязательной модификации жизненного цикла контекста — есть хорошо, и хорошо весьма.

Срок жизни такого замыкания ограничен блоком, в котором объявлена лямбда. А значит за пределами этого блока при обращении к лямбде ждет UB. Т.е. лямбду можно передать аргументом, но вернуть в качестве результата ни лямбду, ни что-то ее использующее нельзя. Как можно говорить о классическом замыкании то что работает как замыкание только в одну сторону?

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

c> с учетом того, что компьютерное время все более и более дешево в сравнении с человеко-часами, затрачиваемыми на разработку

Зависит от <количества серверов в стойке>.

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

S>Срок жизни такого замыкания ограничен блоком, в котором объявлена лямбда. А значит за пределами этого блока при обращении к лямбде ждет UB. Т.е. лямбду можно передать аргументом, но вернуть в качестве результата ни лямбду, ни что-то ее использующее нельзя. Как можно говорить о классическом замыкании то что работает как замыкание только в одну сторону?
в с++ лямбда может копировать контекст по значению, тогда UB отменяется.

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

ГВ>>Напротив. Это как раз полное классическое замыкание с некоторой спецификой, свойственной C++ (явное разделение ссылок и значений, const/mutable, далее по тексту). То, что лямбда не навязывает обязательной модификации жизненного цикла контекста — есть хорошо, и хорошо весьма.

S>Срок жизни такого замыкания ограничен блоком, в котором объявлена лямбда. А значит за пределами этого блока при обращении к лямбде ждет UB.

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

class A {
  A(int *p) : p_(p){}
  int *p_;
};

A foo() {
  int a;
  return A(&a);
}

Но если так сделать, то ты сам себе недобрый Буратин. Аналогичное ограничение с лямбдами.

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

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

function<void (int)> g = [](int n) { cout << n * n * n << " "; };

vector<int> a;
vector<int> b;

// ...

auto prime = [](const int n) -> bool {
    if (n < 2) {
       return false;
    }

    for (int i = 2; i <= n / i; ++i) {
        if (n % i == 0) {
            return false;
        }
    }
    return true;
};

keep_if(a, prime);
keep_if(b, prime);

Вполне себе функции со вполне себе распознаваемой сигнатурой.

S>Как можно говорить о классическом замыкании то что работает как замыкание только в одну сторону?

ИМХО, можно. Просто вопросы согласования жизненных циклов, как обычно, лежат на программисте. Само по себе замыкание от этого неполноценным не становится, но (как это всегда бывает на C++) нужно контролировать, что именно происходит с твоими переменными.

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

ГВ>Я имел в виду Part 1.

Собственно, что и ожидалось. Недолямбды в недоязыке.

Of course, if a lambda function object outlives local variables that it has captured by reference, you get crashtrocity.

В прочем, это лучше чем есть сейчас. Лучше хоть что-то, чем ничего.

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

ГВ>ИМХО, можно. Просто вопросы согласования жизненных циклов, как обычно, лежат на программисте. Само по себе замыкание от этого неполноценным не становится, но (как это всегда бывает на C++) нужно контролировать, что именно происходит с твоими переменными.

Еще как стаовится. Исчезает целый класс применения.

В общем, будет еще больше багов.

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

Х>в с++ лямбда может копировать контекст по значению, тогда UB отменяется.

Ты забыл добавить, что при этом отменяются высокая производительность и некоторые области применения. А как только данные начинают передоваться по ссылке, то здравствуй UB и море багов.

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

VD>Собственно, что и ожидалось. Недолямбды в недоязыке.
VD>

VD>Of course, if a lambda function object outlives local variables that it has captured by reference, you get crashtrocity.

во-первых, ето полноценные лямбды и полноценные замыкания, ты ето сам прекрасно знаешь и к чему ета клоунада "недолямбды в недоязыке" мне непонятно, во-вторых, тебе как к очередному фанату управляемой памяти вопрос, где написано что замыкания обязаны захватывать контекст по ссылке и никак иначе?

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

VD>Ты забыл добавить, что при этом отменяются высокая производительность и некоторые области применения. А как только данные начинают передоваться по ссылке, то здравствуй UB и море багов.
ой ли, ты часто передаёшь лямбды после выхода из scope? как раз таки остутствие гц и возможность захватывать контекст по ссылке обеспечивает экстремальную производительность (нет боксинга для стековых объектов как в дотнете, ага). Ещё раз, ето юмор такой или что? лямбды в с++ предлагают два варианта захвата контекста, причём можно гибко выбирать что захватывать по ссылке, что по значению. Таких гибких лямбд нет ни в одном языке программирования, назвать ето "недолямбдами" и "ограничением области применения" можно разве только по причине шаблонности мышления.

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

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

ГВ>

ГВ>

ГВ>Но если так сделать, то ты сам себе недобрый Буратин. Аналогичное ограничение с лямбдами.
Об этом и говорю.

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

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

ГВ>

ГВ>function<void (int)> g = [](int n) { cout << n * n * n << " "; };
ГВ>

Нет замыкания...

ГВ>

ГВ>vector<int> a;
ГВ>vector<int> b;

ГВ>// ...

ГВ>auto prime = [](const int n) -> bool {
ГВ>    if (n < 2) {
ГВ>       return false;
ГВ>    }

ГВ>    for (int i = 2; i <= n / i; ++i) {
ГВ>        if (n % i == 0) {
ГВ>            return false;
ГВ>        }
ГВ>    }
ГВ>    return true;
ГВ>};

ГВ>keep_if(a, prime);
ГВ>keep_if(b, prime);
ГВ>

И тут нет замыкания

S>>Как можно говорить о классическом замыкании то что работает как замыкание только в одну сторону?

ГВ>ИМХО, можно. Просто вопросы согласования жизненных циклов, как обычно, лежат на программисте. Само по себе замыкание от этого неполноценным не становится, но (как это всегда бывает на C++) нужно контролировать, что именно происходит с твоими переменными.
Т.е. если захотелось передать лямбду с замыканием наружу — то как надо поступить?