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

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

С помощью делегата можно! 



Ну уж хотя бы потому, что при инициализации объекта вы затратите чёрт знает (разработчик знает) сколько памяти. А при вызове через делегат - расход только на делегат.
Енто раз.

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

Енто два.

С помощью делегатов можно делать последовательность вызовов функций (поскольку к делегату можно прицепить не одну функцию).

Енто три.

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

Енто четыре.

Например, возьмём LINQ.

Берём любой int массив обыкновенный (System.Array)



Функция Where принимает делегат Predicate(здесь я написал лямбда-выражение).
Благодаря делегатам пользовать массива может делать что хочет, задавать какие хочешь функции для работы с массивом, чтобы вернуть то, что надо.


Это сообщение отредактировал(а) ДобренькийПапаша - 25.8.2010, 13:30

интересно - а каким ты образом реализуешь события на такой архитектуре? 

ничего ацкого в делегатах нет. как ты уже и говорил - делегаты это просто указатели на функции( только типобезопасные), т.е. это как callback функции в С++. 


ха! посмотри тот же STL. Да там все алгоритмы реализованы с предикатами. А это и есть ни что иное, как указатели на функции.

Так что по аналогии с С++ все симметрично + безопасность + дополнительный функционал объекта папы-делегата (см. док)

Добавлено через 2 минуты и 6 секунд
в общем твоя проблема не в делегатах - а в смысле функций обратного вызова - как таковых  

Почитал вики с гуглом. Сформулировал вопрос: причина введения в язык указателей на функции (как их называют "обратного вызова") -- технические или архитектурные? Из-за специфики железа (связанные со стеком или еще чем) или из-за плюшек с той же событийной модели? Читаю и не могу выделить основную причину.

Сейчас основная причина - архитектурная. Событийная модель издатель-подписчик это комильфо!  ИМХО  

да


да.

Мсдн, интуит, гугл, книги.. Щас каша в голове. Архитектурно мой мозг имеет такая схема:
1. Объект-отправитель - класс с event-полями, которые на самом деле не поля, а классы.
2. Объект-получатель - класс, где есть метод(ы) для активации по событию. 
Связь. Где что пишут, даже не знаю, что правильно. Варианты, какие прочитал:
1. В объект-получатель передать ссылку на объект-отправитель, вызвать его event-поле и присвоить метод-обработчик.
2. 

Либо это "обложка" для программиста и на самом деле компилятор "развернет" его по варианту 1. Т.е. в нечто вроде этого:

либо есть несколько способов подписаться на событие.

Это сообщение отредактировал(а) Gunslinger - 30.8.2010, 10:24

Возьми Троелсена и почитай главу про делегаты и события, там всё очень хорошо разъясняется. Твои вопросы отпадут сами собой..