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

WF>Что-то я протупил. Действительно, в этом случае можно просто полностью скопировать контекст. Правда, остается другая проблема. Если захваченная локальная переменная — указатель (немодифицируемый), указывающий на другую локальную переменную. Указатель скопируется, но то, на что он указывал — помрет.

Что значит помрет? Метод получит копию. Единственная проблема заключается в том, что это будет копия на момент первого обращения к методу. Конечно это противоречит идее импиративного языка и снижает возможности, но за то просто в реализации и не создает побочных эффектов.

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

V>О каком общем фоне речь? У кого хватает ошибок при многопоточном программировании? Шутку понял, но ты утрируешь.

У всех. Многопоточный код традиционно более глючный.

VD>>Еще раз. Не модифицируй переменные в анонимных методах и проблем никогда не возникнет.

V>Аналогично. Хотя, твое утрирование вышло за разумные рамки. Кто не должен модифицировать переменные? И нафига они тогда нужны?

Целая куча языков живут вообще без модификации переменных и ничего. Лучше что-то чем ничего. Определили переменную и ладно... Заморозили ее значение и используем... Замораживать можно при получении ссылки на метод.

VladD2,

> A>Не трудно продемонстрировать примером? Чтобы вроде этого вышло:
> A>

> A>void fun1(int a)
> A>{
> A>    cout << a << endl;
> A>}
>
> A>void fun2(short a)
> A>{
> A>    cout << a << endl;
> A>}
>
> A>int main()
> A>{
> A>    signal<void (int)> fun;
> A>    fun.connect(&fun1);
> A>    fun.connect(&fun2);
> A>    fun(10);
> A>}
> A>

>
> Это пример нарушения работы с типами. Идет усечение данных без явного приведения типов (неговоря уже о контроле переполения). Так что печально, что такое вообще можно сделать.

По-моему, речь шла о другом: поддерживают ли делегаты все те же неявные преобразования, что разрешены при вызовах функций в данном языке. Какие конкретно разрешены неявные преобразования в том или ином языке — разговор отдельный, к делегатам/сигналам не относящийся. Давай, чтоб не отвлекаться, сделаем так, чтоб усечения не было, но неявное преобразование осталось:

void fun1(int a)
{
     cout << a << endl;
}

void fun2(long a)
{
     cout << a << endl;
}

int main()
{
     signal<void (int)> fun;
     fun.connect(&fun1);
     fun.connect(&fun2);
     fun(10);
}

Итак?..

VladD2,

> WF>Что-то я протупил. Действительно, в этом случае можно просто полностью скопировать контекст. Правда, остается другая проблема. Если захваченная локальная переменная — указатель (немодифицируемый), указывающий на другую локальную переменную. Указатель скопируется, но то, на что он указывал — помрет.

> Что значит помрет? Метод получит копию.

Копию указателя. А то, на что данный указатель указывает, — вполне может помереть.

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


VD>Это пример нарушения работы с типами. Идет усечение данных без явного приведения типов (неговоря уже о контроле переполения). Так что печально, что такое вообще можно сделать.

Да, тут я наврал. Со свичом /Wall, наверное, можно было выявить. Но фишка не в этом. Я мог бы использовать long вместо short. Фишка в том, что boost::signal не требует точного соответствия типов параметров. Если существует приведение типов к нужным, оно будет задействовано. Именно это и имелось ввиду в сравнении boost::signal с .NET delegates.

А ковариантные возвращаемые значения — это basics. Странно, что только в v2 они стали поддерживаться delegate'ами.

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

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

...
A>А ковариантные возвращаемые значения — это basics. Странно, что только в v2 они стали поддерживаться delegate'ами.

Неправильно выразился. Ковариантные параметры.

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

C>Релиза официального нет? Тогда свободны (а то я могу сказать, что TR1 и
C>XTI (eXtended Type Information) для С++ давно уже доступны — для тех кто не жмурится).

Дай ссылку на место откуда они возможны, плиз.

C>А если в процессе обработки getData произойдет изменение списка
C>слушателей? Так что пробуйте дальше.

Как говорил Альф "а если не сработает ваше земное притяжение?".
Хреново ты дотнет знашь. Не может измениться список. Списка слушателей нет. Есть список вызовов (реальных ссылок на пары метод/объект). Так вот этот список неизменяемый. При комбинировании делегатов или при создании нового просто пораждается новый делегат с новым списоком. 1:1 как в ФЯ. При этом никаких проблем с синхронизацией не может быть в принципе.

>> Что не сильно сложнее, но особого смысла не имеет.

C>Это только так кажется.

Что кажется и почему? Обоснуй, плиз.

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

Рефлекшен в С++ вроде как появится. А вот то что описанная мной динамика появлися я лично сильно сомневаюсь. Разубеди, плиз.

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

C>Это скорее всего можно будет сделать.

Ой сомневаюсь я...

C>Можно, но код будет не сегодня — некогда. Опишу пример словами:
C>1. Есть сигнал и набор слушателей, слушатели разделяются на несколько
C>уровней приоритета (слушатели должны вызываться в порядке убывания
C>приоритета).
C>2. Каждый обработчик может запретить вызов дальнейших обработчиков.
C>3. Каждый обработчик возвращает целое число, после обработки всех
C>сигналов я должен получить список возвращенных значений.

Не слишком сложно?

Здравствуйте, Павел Кузнецов, Вы писали:

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

Дык в данном языке в C# неявное приведение int к short как раз и не разрешены.

ПК> Какие конкретно разрешены неявные преобразования в том или ином языке — разговор отдельный, к делегатам/сигналам не относящийся. Давай, чтоб не отвлекаться, сделаем так, чтоб усечения не было, но неявное преобразование осталось:
ПК>

ПК>void fun1(int a)
ПК>{
ПК>     cout << a << endl;
ПК>}

ПК>void fun2(long a)
ПК>{
ПК>     cout << a << endl;
ПК>}

ПК>int main()
ПК>{
ПК>     signal<void (int)> fun;
ПК>     fun.connect(&fun1);
ПК>     fun.connect(&fun2);
ПК>     fun(10);
ПК>}
ПК>

ПК>Итак?..

Никак. Изменить размер памяти невозможно. Но переходник легко решает данную проблему. А вот подобная сущность сразу становится не компонентной, так как зависит от размеров типов конкретной функции и в рантайме с ней будут огромные проблемы.

В общем, веселые времена будут если в С++ таки введут рефлекшон, но не сделают полноценной ссылки на методы. Ну, да за то на наш форум по С++ будет процветать.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Копию указателя. А то, на что данный указатель указывает, — вполне может помереть.

А что в С++ когда-то было по другому? В данном случае ничего не меняется.

VladD2,

> ПК>По-моему, речь шла о другом: поддерживают ли делегаты все те же неявные преобразования, что разрешены при вызовах функций в данном языке.
>
> Дык в данном языке в C# неявное приведение int к short как раз и не разрешены.

Тогда к чему эти возгласы о нарушении работы с типами? В системе типов C++ (и, как ты утверждаешь, C#) типы int и short совместимы...

> ПК>

> ПК>     signal<void (int)> fun;
> ПК>     fun.connect(&fun1);
> ПК>     fun.connect(&fun2);
> ПК>     fun(10);
> ПК>

> ПК>Итак?..

> Никак. Изменить размер памяти невозможно. Но переходник легко решает данную проблему.

Размер памяти здесь совершенно ни при чем: boost::signal порождает именно такие переходники, как ты описываешь (если я правильно понимаю, о чем ты говоришь), автоматически, в точке привязки функции к сигналу.

VladD2,

> ПК> Копию указателя. А то, на что данный указатель указывает, — вполне может помереть.

> А что в С++ когда-то было по другому? В данном случае ничего не меняется.

Меняется: копирование становится скрытым, неочевидным.

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

C>eao197 wrote:

>>>> А откуда слухи о появлении в C++ рефлекшена?
>> C>Это не слухи, Страуструп усиленно продвигает XTI еще с 99 года.
>> А точной ссылкой на описание XTI не поделишься?

C>Вот презентация от Страуструпа:
C>http://lcgapp.cern.ch/project/architecture/XTI_accu.pdf

C>Где-то я видел ссылку на более новую версию, но вот где именно — точно
C>не вспомню.

C>--
C>С уважением,
C> Alex Besogonov (alexy@izh.com)

Очень интересно. И, похоже, реализуемо заточкой gcc.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

WF>>В точке создания замыкания, там где new delegate() {...}. Там захватывается текущий контекст — биндинги переменных.

VD>Нет никаких "точек зрения замыкания". Анонимный метод имеет свой контекст. В него попадают локальные переменные внешнего метода. Обычный метод тоже имеет свой контекст, но в него не попадают локальные переменные.

Точка создания. Контекст — штука динамическая, при одном вызове метода create переменная val (имя val) связана (т.н биндинг) с одной областью хранения (некоторое место в стеке), при втором вызове — с другой. Вот эти биндинги и запоминаются. В общем, забей.

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

Кстати, цитата из Википедии:
[quote]
Support for closures is introduced in version 2.0 of C#. In C#, they are called "anonymous methods".
[/quote]

VD>В общем, замыкание плохой термин. Он путает. По этому я и пользуюсь словом делегат.

Отлично, VladD2!! Пять баллов!

WF>> а замыкание все еще может быть.

VD>Блин, не замыкание, а анонимный метод. Он и будет со своей копией данных полученной при его создании.

Нет, именно сущность под названием "замыкание". Функция + контекст = замыкание.


Ладно, это уже спор о терминах.

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

WF>Кстати, цитата из Википедии:
WF>[quote]
WF>Support for closures is introduced in version 2.0 of C#. In C#, they are called "anonymous methods".
WF>[/quote]

Замечу, что я не согласен с этим куском Если что, я вообще нигде не говорил, что анонимный метод = замыкание. Анонимный метод — "статическая" сущность программы (т.е существует в коде), замыкание — "динамическая" (т.е возникает только при выполнении программы, в коде замыканий нет, есть только код порождения замыкания).

Анонимные методы были приведены в пример исключительно потому что они гораздо интереснее, чем "внешние" методы (не вложенные в другие методы). Подошли бы и просто вложенные методы, но ведь их нет, не так ли?

VD>>В общем, замыкание плохой термин. Он путает. По этому я и пользуюсь словом делегат.

WF>Отлично, VladD2!! Пять баллов!

Если непонятна ирония, это я к тому, что не хочу пользоваться ad-hoc определениями. Есть устоявшееся понятие, если оно тебя путает, это не значит, что надо его заменять сиюминутными "делегатами".

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

VD>>>И на этом уровне проблем вообще нет. Почитай хотя бы документацию по Дельфи.


Что-то не нашел я там замыканий. Ссылки на функции, даже ссылки на методы конкретного объекта есть, а вот замыканий не вижу.


Насколько я помню, в Дельфи вроде бы можно функции одна в другую вкладывать. Можно ли сделать так, чтобы две вложенные функции (например, InnerA и InnerB) общались через локальную переменную во "внешней" функции.

Псевдо-код (Дельфи плохо знаю).

function Outer() : ??? {некий тип};
var
   val : Integer;
   A: function(): Integer;
   B: function(): Integer;
begin
    val := 0;
    function InnerA
    begin
        inc(val);
        InnerA := val
    end;
    function InnerB
    begin
        dec(val);
        InnerB := val
    end;
    A := InnerA;
    B := InnerB;
    { Как-то возвращаем A и B наружу }
end;

Так вот. Если эти A и B вернуть наружу Outer, то вызывая их по-очереди, что получим?

Например, каков будет результат последовательности:

A();
A();
s := B();

s должно быть 1 (два раза увеличили val, один раз уменьшили).

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

VD>Так вот замыкание — это метод с контекстом. Выразить это можно как указатель на метод. Вот делегат и является таким указателем.

Замыкание — действительно метод с контекстом, а делегат — указатель на метод. Но вот выразить "метод с контекстом" как "указатель на метод" не получится. Поэтому делегаты — не замыкания.

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

Т>Замыкание — действительно метод с контекстом, а делегат — указатель на метод. Но вот выразить "метод с контекстом" как "указатель на метод" не получится. Поэтому делегаты — не замыкания.

В .NET 2.0 ссылка типа "делегат" может ссылаться на замыкание.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>VladD2,

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

Согласен, язык кривоват, но пример то предлагалось создать на Шарпе.

ПК>Тогда к чему эти возгласы о нарушении работы с типами? В системе типов C++ (и, как ты утверждаешь, C#) типы int и short совместимы...

А нарушение оно не в С++. Оно по жизни.

ПК>Размер памяти здесь совершенно ни при чем: boost::signal порождает именно такие переходники, как ты описываешь (если я правильно понимаю, о чем ты говоришь), автоматически, в точке привязки функции к сигналу.

Возможно. Мне казалось, что он просто генерирует специализации под конкретные типы.

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

A>А ковариантные возвращаемые значения — это basics. Странно, что только в v2 они стали поддерживаться delegate'ами.

Откроыенно говоря ко/контрвариантность мне за 3 года ни разу не потребовались. Понятно, что так логичнее, но...

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Меняется: копирование становится скрытым, неочевидным.

А в С++ что-то было очевидным и не скрытым? Ты меня пугашь. Или ты про новый стандарт?