Вопрос

Actually I have been using signals and slots while programing in Qt. The main use of signals and slots are in the UI interaction, for example a clicked button sends a signal that will invoke a slot to perform action. I know that it's possible to use signals and slots for non-gui application, for example a server side application. I looked for other libraries that offers signal and slots and I found boost library. It's some how different from what I learned from Qt. And then I was wondering what's the real utility of signals and slots, since I can manually call a function to perform an action at a given time.

for example in boost here is an example of signals/slots :

#include <boost/signals2.hpp>
#include <iostream>

void mySlot(){
  std::cout << "I'm a slot" << std::endl;
}

void main(){
  boost::signals2::signal<void ()> sig;
  // Connecting the slot to the signal.
  sig.connect(mySlot);

  // Emitting a signal that will call mySlot 
  sig();

  return 0;
}

I could simply do the same thing with a simple call of mySlot() isn't it ?

Not that what made me think is that when we try to connect two different slots, they are called in the same order than connection. and if the first slot is blocking ( try to add an infinite loop) the second slots will never be called ! I guess that it's a kind of vector that stores the addresses of the functions and then iterate the loop and call one by one !

What's the magic behind the signals and slots ? or it's only a kind of abstraction for the developer ?

Thank you in advance.

Это было полезно?

Решение

In short: The main idea is decoupling in my opinion.

In longer: With direct function calls, you could not have a well-separate establishment between the common functionality and the clients of it, for instance. There would be a tight coupling unlike with signals and slots because you would need to know at the point of some condition meeting your criteria which methods exactly to call.

If you would like to gain more freedom, like with many other OOP design patterns, you need something like signals and slots. When a common component, let us call it a library, emits a signal, it does not have to be aware of the (potentially not-yet-existing) client interfaces. This makes the common component flexible enough.

It will also keep responsiveness of the application better since it is not a direct call, but processed by the Qt event loop. Arguably, you could circumvent this with custom threading mechanisms, but that would be lotta more work to make it safe enough, and you would end up doing something close this in the end of the day.

Другие советы

Signals and slots are simply a communication mechanism that can be used across different threads of execution. That is the main value (especially in a GUI focussed library such as QT). Usually there is 1 thread responsible for drawing and managing the graphical side of the application and 1 or more worker threads. Using signals and slots it is possible to abstract away from this. If you wanted to use direct function calls you'd need to synchronise the threads which would lead to reduced performance and responsiveness on the GUI side.

Indeed within one execution thread it does not make much sense using signals and slots. The value comes in when you want to communicatie between processes (on the same machine or between different machines).

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top