Сигналы и слоты Qt - предназначены они только для графического интерфейса или для всей архитектуры приложения?

Question

Мне очень любопытно - сигналы и слоты Qt (паттерн делегата?) Предназначены только для обратного вызова с графическим интерфейсом, или они идеально подходят и предназначены для всего приложения? Я имею в виду, лучше ли разбивать приложение на маленькие, автономные объекты (классы) и связывать их через сигналы и слоты. И если да, то каков рекомендуемый способ возврата значения из сигнала (сигнала, подобного запросу, который используется для возврата чего-либо), поскольку возвращаемые значения сигналов Qt игнорируются.

Answer 1

Сигналы и слоты QT не предназначены для возврата значений из приемника. Это строго односторонний механизм общения.

Получатель может фактически находиться в совершенно другом потоке, получая сигнал из очереди, после того, как отправитель emit вернул вызов.

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

Answer 2

Сигнал и слоты - это способ реализации шаблона наблюдателя . Везде, где вы используете шаблон наблюдателя (например, для уменьшения связи), вы также можете использовать сигналы и слоты.

Answer 3

Сигналы и слоты были созданы для имитации обмена сообщениями между объектами на уровне библиотеки (потому что C ++ не поддерживает сообщения, как Smalltalk), поэтому вы можете использовать их в любом месте, где вы хотите, чтобы объекты общались друг с другом (либо для передачи некоторых данные вокруг или чтобы активировать что-то ... и т. д.). Я использовал их почти для каждой вещи, и они работали нормально, единственная проблема, которую я получил, была с параллельным кодом, когда у меня было несколько потоков, взаимодействующих друг с другом, используя сигнал и слоты, это было действительно плохо (мне требовалась обработка сообщений в реальном времени), потому что исполнение слота не было немедленным.

Я не думаю, что вы можете использовать сигналы для возврата значения (а вы не должны), потому что поступают сигналы для передачи данных другим объектам

/ * если у вас есть конкретные проблемы, которые Вы хотите решить, попытайтесь объяснить это может быть есть способ решить это * /.

Answer 4

Вы можете использовать их для всего.

Они очень хорошо работают для сетевого кода для instnce

Answer 5

В частности, в ответ на возвращаемые значения я не чувствовал, что сигналы и слот Qt представляют собой хороший механизм возвратно-поступательного движения. Как уже упоминали другие, они очень хорошо работают в схеме / роли наблюдателя. Если вы подумаете об этом, есть потенциальные проблемы с возвращаемыми значениями ... например, что происходит, когда к сигналу подключено более одного слота, и каждый из них возвращает разные значения? Те же проблемы возникают в библиотеках SigC ++ и Boost :: Signals, где у каждой есть (разный?) Механизм для ее решения или, по крайней мере, выяснение того, что вы получите.

Если вам действительно нужно возвращаемое значение, я нашел два относительно хороших способа управления им. Первый - использовать механизм событий Qt для запроса данных, а затем передать запрошенные данные в ответ. Обратите внимание, что у событий нет встроенного способа выполнения ответов, поэтому вам потребуется расширить QEvent, чтобы иметь возможность обрабатывать этот случай. На самом деле, мы делаем это в приложениях на моей работе. Он хорошо работает для многопоточного приложения, когда вам нужен асинхронный механизм. Недостаток этого метода заключается в том, что запрашивающему необходимо знать об объекте, с которого он запрашивает данные (для отправки события). Отвечающий объект не должен знать больше, чем запрос и как отправить ответ, который обычно закодирован в запросе. Обратите внимание, что это почти противоположность модели наблюдателя.

Второй метод - передать объект функтора объекту, который должен иметь возможность запрашивать данные. Это работает намного лучше с хорошей библиотекой абстрактных функторов, которая позволяет инкапсулировать объекты и функции, такие как вышеупомянутые SigC ++ или Boost :: Signals. Это также хорошо работает в ситуациях, когда вам нужен немедленный ответ - вы запускаете оператор функтора, и он возвращает значение, прежде чем продолжить обработку в функции. Это также позволяет вам написать объект, похожий на тот, который вы сделали бы с механизмом сигнал / слот, где объект, которому нужно возвращаемое значение из функции (сигнал), не должен ничего знать о том, где был функтор (соединение сигнала) сделал или пришел. Он просто запускает функтор по мере необходимости.

Answer 6

Реализация сигналов и слотов из Qt довольно гибкая. Это определенно не ограничено элементами GUI. Существует даже отдельный механизм передачи сигналов в очереди, который позволяет передавать сигналы из одного потока в другой.

Если вы действительно считаете, что вам нужно, вы можете передать ссылку или указатель внутри сигнала, это позволит вам передавать информацию обратно в излучающий объект. Но я был бы осторожен с чтением сигналов и когда соответствующие слоты выполняются. Существует два режима на передачу и выполнение сигнала на приемниках, немедленный и в очереди. Если вы используете сигнализацию через потоки, потребуется очередь, а затем сразу же возвращается emit.

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