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

а иногда так

Вопрос: как Вы считаете, какой из этих методов предпочтительнее ?
Спасибо.

нормальный сишный стиль. но как быть с доступом к приватным данным класса? как с биндингом аргументов?


чтоб поменьше писать - лямбда/boost::bind().
если же есть требования к производительности - тогда указатели на методы.

но это имхо, естественно.

Я обычно поступаю так: если колбэк один (одна функция), то использую boost::function (который реализуется через функтор или указатель на функцию или что душа пожелает), а если реакций несколько (на несколько событий), то делаю абстрактный класс-колбэк с соответствующим числом методов.
boostcoder, доступ к переменным значения не имеет: с точки зрения принимающего алгоритма колбэк (или 5 колбэков) должен быть абстракцией типа "а что ты скажешь вот на это?". Так что вопрос реализации - дело чисто вкуса удобства.

Добавлено @ 12:41
С-шный указатель на функцию годится только для реализации колбэка, но не как определение - ибо слишком негибок. Хотя, конечно, бывают ситуации, когда точно известно, что дело будет происходить внутри класса (или иерархии классов), и тогда есть смысл использовать самое простое (указатель на функцию-член).

boostcoder, Earnest, спасибо. Но я забыл упомянуть (каюсь) об одном нюансе - в большинстве случаев я не могу пользоваться шаблонами в интерфейсе, т.к. мы частенько "заворачиваем" реализацию в dll-ки, а наружу "торчит" лишь интерфейс. Т.е. связывание происходит не в compile-time, а в runtime.

В этом случае (указатель на функцию-член) я должен знать о классе, который принимает колобок, а это нехорошо... Разве что как во втором примере с абстрактным классом, но тогда и разницы никакой нет.
Мне лично больше нравится второй вариант. Единственный плюс отдельных колбэков - некоторые можно оставить NULL, указывая тем самым, что они не используются. С абстрактным интерфейсом типа Listener такой трюк не пройдёт.

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

Почему не пройдет?




Вот и проходит, как вы, кстати, и писали.

А я бы сделал не один указатель на листенер, а список указателей и методы addListener(Listener*) и removeListener(Listener*). Но возможно это всего лишь Java наложила отпечаток на мой способ мышления. 

Это сообщение отредактировал(а) kosmonaFFFt - 16.1.2012, 15:14

Это с какой стороны смотреть. Я вот считаю, что не плюс, а минус - надо проверять метод прежде чем вызвать
А что касается наследников колбэка-интерфейса - так я обычно не парюсь насчет "абстрактной чистоты", а делаю некоторые методы определения интерфейса не чистыми, а "пустыми" (чтобы не требовалось обязательное переопределение). Это же C++, а не IDL: делай что хочешь, только отвечай за то, что делаешь.

плюс отдельных функторов это легкая комбинируеммость... однако не всегда она нужна.. 

Я пользуюсь сигналами.

Это если есть 0x64%-ная уверенность в том, что тот, кто использует твою dll-ку, пользует тот же фреймворк (boost, Qt etc.), что и ты. Конкретно в моём случае есть ровно такая же уверенность в том, что dll-ка будет юзаться на разных фреймворках разными (по уровню знаний программирования) людьми.

Я тему не читал, только первое сообщение. Тогда мне больше нравится второй вариант.

как много в этой фразе.. © 
1. наступление события можно ассоциировать с разным методом ( как у вас в примерах), а можно с разной структорой данных.. 
2. нет общего решения на все случаи жизни, для каждой модели ответного взаимодействия наиболее полно подходит разное решение..

Добавлено через 2 минуты и 33 секунды
для рантайм совместимости можно делать стык в С-стиле, и удобную обертку для пользования.. 

Что ж. Кратко и понятно (впрочем, как всегда).
Походу, нет в жизни щазтья  (It was a joke, если чо)
Всем откликнувшимся спасибо. Закрываю.