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

AVK>Насчет более примитивного согласен, на счет более базового нет. Нет под делеагтами никакого более базового понятия, делегат это примитив платформы.

Да нет, не примитив. Делегат — это экземпляр вполне конкретного класса. "Кишки" этого класса описаны другими примитивами.

ПК>>emit не является языковым средством,

AVK>Делегат вобщем то тоже. В .NET граница между рантаймом и языком сильно размыта и рассматривать язык отдельно от платформы бессмысленно, ибо сам по себе C# штука малополезная.

+1 за выделенное. Собственно, в этом суть, наверное. В С++ нам дан типизированный указатель на метод, чтобы мы имели инструментарий "сделать все свои дела" в compile-time. В противоположность этому, в дотнете есть сильная поддержка run-time (причем, явно зависящая от реализации), поэтому наружу выставляются т.н. "примитивы" более высокого уровня, инкапсулирующие подробности конкретной реализации. Например, в реализации делегатов от MS есть дескриптор метода, хранится этот дескриптор в поле типа IntPtr. Интерпретацией этого значения занимается фреймворк, а не мы... Вот, собсно, отличие, ибо в С++ мы сами занимаемся интпретацией своих данных.


ПК>>Если доходить до подобных средств, то можно и Reflection в некотором виде реализовать путем анализа Debug Info...

AVK>Нельзя. Потому что и на Debug Info внятного стандарта по крайней мере на x86 нет (у нас тут пришлось поковыряться), и информации там сильно меньше, чем дает рефлекшен.

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

Да и вообще... Пора отходить от хранения кода в текстовых файлах. И в С++ тоже Надо хранить код в специальных репозиториях, полностью описывающих мета-часть кода. Половину задач про рефлекшен и поддержку RAD решили бы.

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

S>[/c#]
S>Смысл, надеюсь, более-менее ясен тем, кто пишет на С++. Те самые cryptic declarations + cryptic usage Но, есть еще
S>3. Можно добиться нужной функциональности, сместив точку зрения:
S>

S>public delegate void UnBoundDelegate(MyClass self, int i);
S>public static Method1(MyClass self, int i)
S>{
S>    self.DoSomethingWeirdWith(i);
S>}
S>public static Method2(MyClass self, int i);
S>{
S>    self.DoSomethingEvenMoreWeirdWith(i);
S>}
S>public static void Apply(UnboundDelegate u, IEnumerable<MyClass> list, int i)
S>{
S>    foreach(MyClass item in list) u(item, i);
S>}
S>

S>Таким образом, мы вместо неявной недопривязки контекста вызова выражаем этот контекст прямо и недвусмысленно. Хоть запривязывайся.
S>Возможность использовать в качестве UnboundDelegate метод какого-то экземпляра, никак не связанного с классом MyClass, оставим в качестве небольшого бонуса за труды. Ничего страшного, если мы бесплатно получили возможность давать функтору дополнительный контекст.

Сорри не удержался. Аналогично выглядели попытки эмуляции ООП на plain С. А что, любой объект — он и есть контекст самому себе

А если по существу, то unbound method pointer в С++ — это не самоцель, ИМХО. Повторюсь, что это просто инструмент. Инструмент, который позволяет легким движением руки создавать нечто, вроде сущности Delegate в дотнете. Ну а так же, является эффективным решением при реализации диспечеризации.

Насчет "легким движением руки", разве это сложно: http://www.rsdn.ru/Forum/Message.aspx?mid=1252197&only=1

Автор: Павел Кузнецов
Дата: 01.07.05

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

V>Введение делегатов в С++ не даст языку НИЧЕГО.
V>Перечислю более скурпулезно:
V>- не сэкономит ни строчки пользовательского кода
В большинстве случаев да. Но есть моменты с перегруженными и/или шаблонными функциями.
V>- не добавит ни грамма типобезопасности более той, что уже есть;
+1
V>- не расширит круг задач, которые сможет решать язык;
+1
V>- не улучшит понимание языка новичками;
+1
V>- не улучшит ни на один такт процессора эффективность конечных бинарных образов программ;
Не согласен.
Указатель на функцию на x86 может занимать от 4 до 16 байт + указатель на объект (4 байта).
Также нужно учитывать что при вызове виртуальной функции по указателю у нас двойная косвенность, а если еще вспомнить про множественное и виртуальное наследование гду еще и this приходится корректировать...
Если же эту сущьность встроить в язык то коррекцию this и поиск реальной функции можно выполнить во время создания делегата.
Таким образом мы сможем свести затраты паяти указатель на функцию (4 байта) + указатель на объект (4 байта) также при вызове не будет необходимости корректировать this и елозить по таблицам виртуальных функций.

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

V>Да и вообще... Пора отходить от хранения кода в текстовых файлах. И в С++ тоже Надо хранить код в специальных репозиториях, полностью описывающих мета-часть кода. Половину задач про рефлекшен и поддержку RAD решили бы.

Зачем решать половину задачь, когда уже давно решены все?

Негр сидит под пальмой и ничего не делает.
Рядом проходит какой-то богатый буратина...
— Ты что это сдишь под польмой и ничего не делашь?
— А зачем что-то делать?
— Как? Чтобы заработать много денег...
— А зачем мне много денег?
— Ну, как сможешь поехать на отдых сесть под пальмой и ничего не делать!
— Так я уже сижу под пальмой и ничего не делаю.

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

V>А если по существу, то unbound method pointer в С++ — это не самоцель, ИМХО. Повторюсь, что это просто инструмент. Инструмент, который позволяет легким движением руки создавать нечто, вроде сущности Delegate в дотнете. Ну а так же, является эффективным решением при реализации диспечеризации.

Легким . И главное здорово то как? Куча кода, траха и все что бы восоздать те самые делегаты. И это при том, что еще в С с указателями на функции небыло ни каких проблем и их можно было использовать без обертывания тонной враперов основанных на шаблонах. Хреновый однако "прогресс".