VladD2 wrote:
> E>Правда? Я вот надеюсь, что boost::bind станет частью языка, тогда > это будет такой же стандартный механизм, как делегаты, а не заплатка. > Не беспокойся — не станет. Я тут прочел твою ссылку на очередное > откровение Страуструпа и понял, что основные вещи он уеж решил (ну, > классы есть же?) а мелочи вроде делегатов или процедурных типов он > делать не желает.
Желает. Сейчас обсуждаются function types, они почти 100%но будут в
Стандарте.
> Это мелкие частности. Ну, что поделать если человек настолко > образован, что ему плевать на целую парадигму функционального > программирования? В общем, орлам вроде Степанова и дальше прийдется > извращаться, чтобы написать примитивную фичу вроде boost::bind. Причем > компилироваться это будет часами. В общем, маразм крепчал...
1. Далеко не все решает один Страуструп.
2. Как раз ФП будет уделено больше внимания (до введения в Стандарт
лямбда-выражений).
Здравствуйте, Cyberax, Вы писали:
C>Желает. Сейчас обсуждаются function types, они почти 100%но будут в C>Стандарте.
Может где-то он и обсуждается. Но хрена два "оно" будет. Тут eao197 дал ссылку на поток мысли Страуструпа перепечатанный CppUJ так из его слов ясно понятно что "все эти функциональные типы — это частности и мелочи. Кульные патцаны ведь народу классы дают. Это куда руче." Бред в общем. Так что если Страус будет конечной инстанцией то шиш с маслом будет вместо делегатов в С++.
C>1. Далеко не все решает один Страуструп.
Будем надеяться, что это так. Иначе хана С++. Убъет его он.
C>2. Как раз ФП будет уделено больше внимания (до введения в Стандарт C>лямбда-выражений).
По словам Страуструпа все немного не так. Ну, не нравится ему простые решения.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> C> Сейчас обсуждаются function types, они почти 100%но будут в Стандарте.
> Может где-то он и обсуждается. Но хрена два "оно" будет. Тут eao197 дал ссылку на поток мысли Страуструпа перепечатанный CppUJ так из его слов ясно понятно что "все эти функциональные типы — это частности и мелочи. Кульные патцаны ведь народу классы дают. Это куда руче." Бред в общем. Так что если Страус будет конечной инстанцией то шиш с маслом будет вместо делегатов в С++.
Я так ты ведешь речь об этом высказывании:
People comparing languages using lists love such features. The snag is that the problems we face are essentially infinite, so we need an infinity of such specialized features. Examples are Pascal procedure parameters and C# delegates. The alternative traditionally offered by C++ (and before that by K&R C) is to provide very general features from which good programmers can construct solutions to a wide variety of problems. Examples are pointers and classes.
Теперь объясни, как именно это исключает введение стандартных классов, представляющих function type?
> C>2. Как раз ФП будет уделено больше внимания (до введения в Стандарт лямбда-выражений). > > По словам Страуструпа все немного не так.
Можно конкретную цитату?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я так ты ведешь речь об этом высказывании: ПК>
People comparing languages using lists love such features. The snag is that the problems we face are essentially infinite, so we need an infinity of such specialized features. Examples are Pascal procedure parameters and C# delegates. The alternative traditionally offered by C++ (and before that by K&R C) is to provide very general features from which good programmers can construct solutions to a wide variety of problems. Examples are pointers and classes.
Об этом, об этом.
ПК>Теперь объясни, как именно это исключает введение стандартных классов, представляющих function type?
Стандарные классы без изменения языка — это маразм. Зачем объходить проблемы лепя горы кода и получая совершенно неудобоваримый результат вместо того чтобы встроить в язык саму собой напрашивающуюся вещь?
ПК>Можно конкретную цитату?
Ты ее привел сам.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
People comparing languages using lists love such features. The snag is that the problems we face are essentially infinite, so we need an infinity of such specialized features. Examples are Pascal procedure parameters and C# delegates. The alternative traditionally offered by C++ (and before that by K&R C) is to provide very general features from which good programmers can construct solutions to a wide variety of problems. Examples are pointers and classes.
> ПК>Теперь объясни, как именно это исключает введение стандартных классов, представляющих function type? > > Стандарные классы без изменения языка — это маразм.
Очень доходчиво
> Зачем объходить проблемы лепя горы кода и получая совершенно неудобоваримый результат вместо того чтобы встроить в язык саму собой напрашивающуюся вещь?
В С++ далеко не обязательно вносить изменения в язык, чтоб поддержать нечто, идентичное по удобству использования делегатам C#. Скажем, boost::function не уступают ни капельки.
Введение аналога анонимных делегатов, aka лямбда-функций, действительно, потребует модификации языка. Но и здесь вводить новый тип, видимый пользователю, кроме boost::function, не нужно. Достаточно поддержать удобный синтаксис создания анонимных объектов анонимных классов с перегруженным operator() по месту использования. Что-нибудь в таком духе:
Здравствуйте, VladD2, Вы писали:
VD>Стандарные классы без изменения языка — это маразм. Зачем объходить проблемы лепя горы кода и получая совершенно неудобоваримый результат вместо того чтобы встроить в язык саму собой напрашивающуюся вещь?
Странное рассуждение. В C# весь reflection доступен так же в виде модели экземпляров классов-дескрипторов. Ничего такого в язык не вставлено. Если "узаконить" часть буста (типа как std::type_info), то зачастую, достаточно будет лишь небольшой поддержки компилятором без значительных изменений языка.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В С++ далеко не обязательно вносить изменения в язык, чтоб поддержать нечто, идентичное по удобству использования делегатам C#. Скажем, boost::function не уступают ни капельки.
Уступают, уступают. И еще как. А главное что это гора кода на ровном месте. Указатели на функции-члены в С++ идея плохая. Эмуляция на них нормальных функциональных типов соотвественно тоже. Получается гора кода и немало ограничений.
ПК>Введение аналога анонимных делегатов, aka лямбда-функций, действительно, потребует модификации языка. Но и здесь вводить новый тип, видимый пользователю, кроме boost::function, не нужно. Достаточно поддержать удобный синтаксис создания анонимных объектов анонимных классов с перегруженным operator() по месту использования. Что-нибудь в таком духе: ПК>
ПК>Это и было бы описываемым Страуструпом более общим решением, чем делегаты.
Страуструп как всегда высказался в своем духе "мы даем людям универсальные абстракции вроде классов", типа другие не дают .
Пожизни же нужно сделать примитивную вещь. Ввести указатель на функцию объекта в котором будет и указатель на функцию, и указатель на объект. Для компиляторщиков делов на пол дня. Это будет работать быстро и эффктивно. Ананоимные методы с возможностью получить доступ к внешним переменным тоже очень логичное расширение. Я бы еще добавил возможность описывать вложенные методы.
Все это привело бы к ускорению компиляции и упрощению библиотек и кода. При этом потерь никаких нет. Страуступ много лет назад объяснял решение ввести уродливые указатели на функции-члены борьбой за безопасность. При этом решение вроде делегатов он отвергал на отрез приписывая ему ненадежность. Сейчас же он уже вроде как не против эмуляции той же идиомы на горе шаблонов. И зачем? Может признать свою ошибку и сделать все как надо?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Стандарные классы без изменения языка — это маразм. Зачем объходить проблемы лепя горы кода и получая совершенно неудобоваримый результат вместо того чтобы встроить в язык саму собой напрашивающуюся вещь?
V>Странное рассуждение. В C# весь reflection доступен так же в виде модели экземпляров классов-дескрипторов. Ничего такого в язык не вставлено.
В C# есть делегаты и анонимные методы. Они полностью поддерживаются компилятором в следствии чего их очень просто и удобно использовать. Для компилятора такая поддержка ничего не стоит. А вот для программиста она дает практически молниеносную компиляцию.
V> Если "узаконить" часть буста (типа как std::type_info), то зачастую, достаточно будет лишь небольшой поддержки компилятором без значительных изменений языка.
Чтобы вставить делегаты (клозюры, функциональный тип и т.п.) не нужна какая-то сверхестественная модификация языка. Нужно ввести новый тип указателя. Синтаксис будет практически таким же как при работе с указателями на глобальные функции. Ну, и нужно разрешить объявлять анонимные функции. Это очень небольшие изменения. И просто вселенской глупостью будет если комитет откажется от этого и узаконит бустовскую эмуляцию.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ПК>>В С++ далеко не обязательно вносить изменения в язык, чтоб поддержать нечто, идентичное по удобству использования делегатам C#. Скажем, boost::function не уступают ни капельки.
VD>Уступают, уступают. И еще как.
А именно, как? Опиши конкретно, по пунктам. (не затрагивая лямбда-функции, что является разговором отдельным и, очевидно, требует языковой поддержки)
> Получается гора кода и немало ограничений.
Гора кода где, у пользователя? Если так -- примеры конкретных отличий с точки зрения использования, пожалуйста. В библиотеке не считается, т.к. что стандартная библиотека, что компилятор -- само по себе это с точки зрения пользователя безразлично.
ПК>>Это и было бы описываемым Страуструпом более общим решением, чем делегаты.
VD>Страуструп как всегда высказался в своем духе "мы даем людям универсальные абстракции вроде классов", типа другие не дают
Не дают. Указатель на функцию или указатель на член -- более базовая функциональность, чем делегаты, т.к. последние через первые реализовать можно, а наоборот -- нет.
VD>Пожизни же нужно сделать примитивную вещь. Ввести указатель на функцию объекта в котором будет и указатель на функцию, и указатель на объект. Для компиляторщиков делов на пол дня. Это будет работать быстро и эффктивно.
В чем конкретно будет разница с библиотечным решением? Без эмоций, только конкретные отличия, пожалуйста.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Чтобы вставить делегаты (клозюры, функциональный тип и т.п.) не нужна какая-то сверхестественная модификация языка. Нужно ввести новый тип указателя. Синтаксис будет практически таким же как при работе с указателями на глобальные функции. Ну, и нужно разрешить объявлять анонимные функции. Это очень небольшие изменения. И просто вселенской глупостью будет если комитет откажется от этого и узаконит бустовскую эмуляцию.
Замыкание != делегаты. Для полноценных замыканий необходимо обеспечить возможность захвата контекста вызова.
Я думаю, в случае с C++ основная проблема будет со стековыми переменными. Например, в следующем коде время жизни локальной val продляется до времени жизни делегата.
using System;
public class Test
{
public delegate int retInc();
public static void Main(string[] args) {
retInc func = create();
retInc func2 = create();
Console.WriteLine(func());
Console.WriteLine(func());
Console.WriteLine(func2());
}
public static retInc create() {
int val = 0;
return delegate () {
return val++;
};
}
}
В .NET это решается созданием специального класса, хранящего контекст, используемый в делегате. Т.е переменная val на самом деле будет полем специального объекта, который будет создан в начале вызова метода. И ссылка на этот объект (представляющий собой контекст) будет передана неявная делегату.
В случае C++, мне кажется, такое сделать будет сложнее. В основном, наверное, из-за отсутствия сборщика мусора. Например, если мы помещаем контекст (грубо говоря, локальные переменные) в кучу, то непонятно когда его удалять — он должен жить пока есть хоть один делегат, ссылающийся на него.
То есть если мы в функции create создадим десяток делегатов подряд, использующих одну локальную переменную val (и соотвественно имеющих общий контекст), то контекст должен быть удален только если все делегаты уже умерли.
Собственно, это фишка и называется "замыкание" (возвращаясь к теме замыканий vs делегаты ).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>Здравствуйте, VladD2, Вы писали:
VD>>>Стандарные классы без изменения языка — это маразм. Зачем объходить проблемы лепя горы кода и получая совершенно неудобоваримый результат вместо того чтобы встроить в язык саму собой напрашивающуюся вещь?
V>>Странное рассуждение. В C# весь reflection доступен так же в виде модели экземпляров классов-дескрипторов. Ничего такого в язык не вставлено.
VD>В C# есть делегаты и анонимные методы. Они полностью поддерживаются компилятором в следствии чего их очень просто и удобно использовать. Для компилятора такая поддержка ничего не стоит. А вот для программиста она дает практически молниеносную компиляцию.
V>> Если "узаконить" часть буста (типа как std::type_info), то зачастую, достаточно будет лишь небольшой поддержки компилятором без значительных изменений языка.
VD>Чтобы вставить делегаты (клозюры, функциональный тип и т.п.) не нужна какая-то сверхестественная модификация языка. Нужно ввести новый тип указателя. Синтаксис будет практически таким же как при работе с указателями на глобальные функции. Ну, и нужно разрешить объявлять анонимные функции. Это очень небольшие изменения. И просто вселенской глупостью будет если комитет откажется от этого и узаконит бустовскую эмуляцию.
Ну и как ты себе представляешь продление времени жизни локальных переменных, используемых анонимной ф-ий. Я прекрасно знаю, как это сделано в C# 2.0, тем не менее, на мой взгляд, это тааааакие грабли, при мультипоточном использовании подобных анонимных делегатов. Абсолютно неочевидные и гнусные грабли.
Здравствуйте, WFrag, Вы писали:
WF>Замыкание != делегаты.
Ошибаешся.
WF> Для полноценных замыканий необходимо обеспечить возможность захвата контекста вызова.
Еще раз ошибаешся. Не контекст вызова, а контекст функции. А это разные вещи. Для анонимной функции (лямбды) этот контекст зачастую действительно близок к контексту вызова, но это не обязательно. Так что всегда запоминается контекст описания. Было бы здорово если в С++ ввели анонимные методы, но сами замыкния или делегаты намного важнее.
Или это как раз тот слувай что описан в начале того сообщения ("гляжу в книгу — вижу фигу")?
WF>Я думаю, в случае с C++ основная проблема будет со стековыми переменными. Например, в следующем коде время жизни локальной val продляется до времени жизни делегата.
Проблемы в С++ несомненно будут. Но не технические, а проблемы с тараканами в мозгах его авторов.
WF>В случае C++, мне кажется, такое сделать будет сложнее. В основном, наверное, из-за отсутствия сборщика мусора. Например, если мы помещаем контекст (грубо говоря, локальные переменные) в кучу, то непонятно когда его удалять — он должен жить пока есть хоть один делегат, ссылающийся на него.
В С++ все не просто. Но если проблему решать, то она решается. Ту же скорее проблема в нежеланием решать проблемы. Вместо этого всем объясняется, что все проблемы можно решить библиотеками. Вот это мне и не нравится.
WF>То есть если мы в функции create создадим десяток делегатов подряд, использующих одну локальную переменную val (и соотвественно имеющих общий контекст), то контекст должен быть удален только если все делегаты уже умерли.
Делегаты не могут ссылаться на переменные. Делегаты — это ссылки на функции. Ссылаются сами функции. Сколько можно это повторять?
WF>Собственно, это фишка и называется "замыкание" (возвращаясь к теме замыканий vs делегаты ).
Да, уж. Возвращамся, хотя мне казалась эта тема закрытой.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
VD>>Чтобы вставить делегаты (клозюры, функциональный тип и т.п.) не нужна какая-то сверхестественная модификация языка. Нужно ввести новый тип указателя. Синтаксис будет практически таким же как при работе с указателями на глобальные функции. Ну, и нужно разрешить объявлять анонимные функции. Это очень небольшие изменения. И просто вселенской глупостью будет если комитет откажется от этого и узаконит бустовскую эмуляцию.
V>Ну и как ты себе представляешь продление времени жизни локальных переменных, используемых анонимной ф-ий.
Я в даном случае говорил только о "делегатах/замыканиях/функциональных типах" (далее — делегаты). Ссылаться они могут на обычные функции. Было бы конечно здорово если бы ввели анонимные методы и еще лучше если бы в них сделали возможность ссылаться на локальный контекст, но это все же не боле чем улучшение. А сами делегаты все же важнее. И их то как раз реализовать ничего не стоит. Можно считать, что это поправка старой ошибки.
V>Я прекрасно знаю, как это сделано в C# 2.0, тем не менее, на мой взгляд, это тааааакие грабли, при мультипоточном использовании подобных анонимных делегатов. Абсолютно неочевидные и гнусные грабли.
Мне кажется ты преувеличиваешь. Проблема многопоточного программирования — это отдельная проблема. Она существует без каких бы то нибыло дополнений. И единственный простой ее обход — это постоянно порождать копию данных (в общем использовать функциональный стиль). И тут как раз анонимные методы очень даже неплохо могут себя показать если не менять эти переменные внутри анонимных методов.
Ну, а модификация переменных... Дык это общая проблема императивных языков. Так что если мы говорим о таком на сквозь императивном языке как С++, то рассуждать о потенциальной грабельности модификации переменных в многопоточных программах просто смешно.
ЗЫ
Не оверквоть, плиз.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А именно, как? Опиши конкретно, по пунктам. (не затрагивая лямбда-функции, что является разговором отдельным и, очевидно, требует языковой поддержки)
Начнем с того, что делегаты это намного больше чем просто замыкание. Их можно объеденять. Потом это полноценный компонентный тип. Его можно передать в другие компоненты, по сети и т.п. Его можно создать в рантайме. Они даже могут быть обобщенными. Ну, что-то вроде:
delegate bool Predicate<T>(T t);
Ну, и на его компиляцию практически не тратится времени.
>> Получается гора кода и немало ограничений.
ПК>Гора кода где, у пользователя?
У компилятора. Что неминуемо замедлид компиляцию.
ПК> Если так -- примеры конкретных отличий с точки зрения использования, пожалуйста.
О. Это легко. Создашь два аналогичных примера и нажимашь F5. Далее следишь за тем насколько скоро запустится отлаживаемый модуль. После этого можно попробовать передать boost::function по сети. Ну, в общем можешь и сам придумать.
ПК> В библиотеке не считается, т.к. что стандартная библиотека, что компилятор -- само по себе это с точки зрения пользователя безразлично.
Это если пользователю по барабану результат и удобство.
ПК>>>Это и было бы описываемым Страуструпом более общим решением, чем делегаты.
VD>>Страуструп как всегда высказался в своем духе "мы даем людям универсальные абстракции вроде классов", типа другие не дают
ПК>Не дают.
Что, классов нет? Вауу...
ПК> Указатель на функцию или указатель на член -- более базовая функциональность, чем делегаты, т.к. последние через первые реализовать можно, а наоборот -- нет.
Серьезно? А может поглядеть на эту реализацию? Это выкручивание, а не реализация. Основная проблема подобных реализаций это как раз обход излишне заботливого контроля типов.
Как раз делегатами можно решить все проблемы решаемые "указателем функцию на член", а вот обратное не верно. И выверты реализаций вроде boost::function это прекрасно демонстрируют.
Кстати, просто указатели на члены, и просто указатели на функции тут не причем. Они действительно универсальны и не содержат проблем.
ПК>В чем конкретно будет разница с библиотечным решением? Без эмоций, только конкретные отличия, пожалуйста.
Я уже много раз это говорил. Даже тормоза при компиляции это уже проблемы. А уж то, что это не первокласная функция услжнит жизнь не в одном месте. Например, если все же в С++ появится хоть какой-то рефлекшон, то анализ boost::function станет не хилой проблемой. Между тем анализ встроенного типа проблем не имеет.
В общем, дело не в виде который примет сам указатель. В том же шарпе делегат это тоже класс. Дело в поддежке со стороны компилятора и во внутренней реализации. Если это дело будет выглядеть как boost::function но при этом внутри появится хак, то многие проблемы исчезнут. Но куда логичнее просто ввести новый тип указателя и уже на его базе делать остальные решения.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ПК>>А именно, как? Опиши конкретно, по пунктам. (не затрагивая лямбда-функции, что является разговором отдельным и, очевидно, требует языковой поддержки)
VD>Начнем с того, что делегаты это намного больше чем просто замыкание. Их можно объеденять.
Это делается легко и с boost::function и аналогами.
VD> Потом это полноценный компонентный тип. Его можно передать в другие компоненты, по сети и т.п. Его можно создать в рантайме.
Это уже ограничения среды исполнения: либо она поддерживает подобные вещи, либо нет. В C++ подобной поддержки (по крайней мере, в готовом виде) нет в принципе. От того, что boost::function стал бы, как ты предлагаешь, встроенным типом, эти аспекты бы ни на капельку не изменились бы.
VD> Они даже могут быть обобщенными. Ну, что-то вроде: VD>
VD>delegate bool Predicate<T>(T t);
VD>
Это и для boost::function верно.
VD>Ну, и на его компиляцию практически не тратится времени.
Намного более общим подходом является решение проблем скорости компиляции (введение поддержки модулей и т.д.), нежели введение в язык "хэков" для поддержки всевозможных популярных компонентов: boost::function, std::vector, std::list и т.п.
VD>В общем, дело не в виде который примет сам указатель. В том же шарпе делегат это тоже класс. Дело в поддежке со стороны компилятора и во внутренней реализации. Если это дело будет выглядеть как boost::function но при этом внутри появится хак, то многие проблемы исчезнут. Но куда логичнее просто ввести новый тип указателя и уже на его базе делать остальные решения.
В общем, дальше можно не продолжать: аргументация подобного уровня мне неинтересна.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Еще раз ошибаешся. Не контекст вызова, а контекст функции.
Да, я оговорился. Не контекст вызова, а контекст в точке создания.
VD>Проблемы в С++ несомненно будут. Но не технические, а проблемы с тараканами в мозгах его авторов.
Нет, я хочу сказать что проблема довольно серьезная и вряд ли вообще решаема без серьезных изменений (например, GC). Поэтому твои лихие слова о тараканах в голове мне и не нравятся. Не так все просто, как мне кажется.
Павел Кузнецов wrote:
> ПК>>А именно, как? Опиши конкретно, по пунктам. (не затрагивая > лямбда-функции, что является разговором отдельным и, очевидно, требует > языковой поддержки) > VD>Начнем с того, что делегаты это намного больше чем просто > замыкание. Их можно объеденять. > Это делается легко и с boost::function и аналогами.
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется ты преувеличиваешь. Проблема многопоточного программирования — это отдельная проблема. Она существует без каких бы то нибыло дополнений. И единственный простой ее обход — это постоянно порождать копию данных (в общем использовать функциональный стиль). И тут как раз анонимные методы очень даже неплохо могут себя показать если не менять эти переменные внутри анонимных методов.
Ок, ты немного не понял о чем я.
Речь о другом. Есть некие устоявшиеся постулаты при работе с мультипоточными программами. Например — локальные переменные доступны лишь контексту текущего потока (т.к. стек — это приватный элемент потока). Далее, мы вводим анонимный делегат, который в начале не использует некие локальные переменные. После очередной доработки кто-то незаметно решил попользовать локальную переменную в анонимном коде делегата. И эта переменная незаметно перестала быть стековой. Собственно, в этом суть упомянутых граблей.
VD>Ну, а модификация переменных... Дык это общая проблема императивных языков. Так что если мы говорим о таком на сквозь императивном языке как С++, то рассуждать о потенциальной грабельности модификации переменных в многопоточных программах просто смешно.
Если уточнить, что речь о стековых переменных, то становится уже не смешно, а чуточку страшно. Локальный контекст — это вообще единственная точка опоры при многопоточном программировании.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это делается легко и с boost::function и аналогами.
Мало ли что где делается. Сущьности не равноценны.
VD>> Потом это полноценный компонентный тип. Его можно передать в другие компоненты, по сети и т.п. Его можно создать в рантайме.
ПК>Это уже ограничения среды исполнения: либо она поддерживает подобные вещи, либо нет. В C++ подобной поддержки (по крайней мере, в готовом виде) нет в принципе.
Тем хуже для С++. Но проблема в том, что этой поддержки нет и чужими стараньями. И скорее всего никогда не появится. КОМ и Корба так и будут пользоваться своими велосипедами.
ПК> От того, что boost::function стал бы, как ты предлагаешь, встроенным типом, эти аспекты бы ни на капельку не изменились бы.
Ну почему же? Думаю, разработчики КОМ-а и Корбы нашли бы способ использовать встроенный тип.
VD>> Они даже могут быть обобщенными. Ну, что-то вроде: VD>>
VD>>delegate bool Predicate<T>(T t);
VD>>
ПК>Это и для boost::function верно.
Возможно. Продемонстрируй, плиз, код.
VD>>Ну, и на его компиляцию практически не тратится времени.
ПК>Намного более общим подходом является решение проблем скорости компиляции (введение поддержки модулей и т.д.), нежели введение в язык "хэков" для поддержки всевозможных популярных компонентов: boost::function, std::vector, std::list и т.п.
Модули модулями, но шаблоны есть шаблоны. На их обработку будет тратиться намного больше времени чем на обработку встренного примитива.
К тому же при испльзовании шаблонов в МС++ они приводят к нехилому разбуханию метаинформации, что тоже не здорово.
В общем, я не вижу смысла решать проблемы метапрограммированием там где просто напрашивается введение примитива в язык.
VD>>В общем, дело не в виде который примет сам указатель. В том же шарпе делегат это тоже класс. Дело в поддежке со стороны компилятора и во внутренней реализации. Если это дело будет выглядеть как boost::function но при этом внутри появится хак, то многие проблемы исчезнут. Но куда логичнее просто ввести новый тип указателя и уже на его базе делать остальные решения.
ПК>В общем, дальше можно не продолжать: аргументация подобного уровня мне неинтересна.
Аргументы соврешенно нормальные. Просто вести беседу с людьми которые принципиально уверены в своей правоте бессмысленно. Они всегда находят проблему в собеседнике. Так поступил и ты.
Ты не хочешь воспринимать мои аргументы и априори (без какой либо аргументации) объявляешь их ничтожными.
Счасливо оставаться со своим мнением. Оно не поколибимо.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WFrag, Вы писали:
VD>>Еще раз ошибаешся. Не контекст вызова, а контекст функции.
WF>Да, я оговорился. Не контекст вызова, а контекст в точке создания.
Создания чего? Метода? Да не сомненно.
VD>>Проблемы в С++ несомненно будут. Но не технические, а проблемы с тараканами в мозгах его авторов.
WF>Нет, я хочу сказать что проблема довольно серьезная и вряд ли вообще решаема без серьезных изменений (например, GC). Поэтому твои лихие слова о тараканах в голове мне и не нравятся. Не так все просто, как мне кажется.
Ты очередной раз умудрился не понять, что я говорю. Еще раз. Closur != анонимным методам (или если угодно, ламбдам). Closur == делегат. И на этом уровне проблем вообще нет. Почитай хотя бы документацию по Дельфи.
Ну, а что до анонимных методов, то опять же можно не давать модифицировать контекст (как это делается в функциональных языках). Тоже решение. В общем, решений может быть масса. Было бы желание их искать.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. 
