Сигнал/Слот по сравнению с прямыми [закрытыми] вызовами функции
Это - то, как я думаю о нем (и видели рационализированный другими):
библиотека А является чем-то содержавшим в Вашем коде. И платформа является контейнером для Вашего приложения.
3 ответа
Передача сигнала требует нескольких переключателей и некоторых дополнительных вызовов функций (в зависимости от того, что и как подключено), но накладные расходы должны быть минимальными.
Поставщик сигнала не может контролировать, кто его клиенты есть, и даже если все они действительно получили сигнал к моменту возврата emit.
Это очень удобно и позволяет полностью разъединить, но также может привести к проблемам, когда порядок выполнения имеет значение или когда вы хотите что-то вернуть.
] Никогда не передавайте указатели на временные данные (если вы точно не знаете, что делаете, и даже тогда ...). Если необходимо, передайте адрес своей переменной-члена - Qt предоставляет способ отложить уничтожение объекта до тех пор, пока все события для него не будут обработаны.
Сигналы также могут требовать запуска цикла событий (если, как мне кажется, соединение не является прямым) .
В целом они имеют большой смысл в приложениях, управляемых событиями (на самом деле, без них это быстро становится очень раздражающим).
Если вы уже используете Qt в проекте, определенно используйте их. Если зависимость от Qt недопустима, у boost есть аналогичный механизм.
Есть еще одно отличие. №1 жестко связан с интерфейсом IDataBlock, и класс Updater должен знать о "someblock". №2 может быть позднее присоединен через вызов подключения (или несколько, включая разъединения), что приводит к более динамичному подходу. # 2 действует как сообщение (подумайте о Smalltalk / ObjC), а не как вызов (подумайте о C / C ++). Сообщения также могут подвергаться многократной отправке, что требует ручной реализации этой функции в №1.
Я бы предпочел использовать сигналы / слоты из-за их гибкости, если только производительность кода или потребность в немедленных возвращаемых данных не позволяет этого (или зависимость от Qt нежелательна).
Две формы могут показаться похожими. Функционально это правда. На практике вы решаете большую проблему. В этих случаях внешние обстоятельства сделают эти два решения не эквивалентными.
Обычный случай - выяснение отношения между источником и приемником. Они вообще знают друг друга? В вашем первом примере updateData () необходимо передать приемник. Но что, если триггером является кнопка графического интерфейса [Обновить данные]? Кнопки являются общими компонентами и не должны знать об IDataBlock.
Решением, конечно же, является добавление члена m_someblock в Updater. Кнопка теперь обновит любой член, находящийся в Updater. Но действительно ли это то, что вы хотели?