Using emit vs causes a signal as if it is a regular function in Qt

Question

Let's say I have this signal:

signals: void progressNotification(int progress); 

I only recently found out about the emit keyword in Qt. So far, I have used signals, just calling them as a normal function. Therefore, instead of:

 emit progressNotification(1000 * seconds); 

I would write:

 progressNotification(1000 * seconds); 

Call them, how it seemed to work, and all connected slots would execute, so using the emit keyword causes a different behavior or is it just syntactic sugar?

Answer 1

emit is just syntactic sugar. If you look at the pre-processed output of a function that emits a signal, you will see that emit just left.

"Magic" occurs in the generated code for the signal emitting function, which you can see by checking the C ++ code generated by moc.

For example, a signal foo without parameters generates this member function:

 void W::foo() { QMetaObject::activate(this, &staticMetaObject, 0, 0); } 

And the code is emit foo(); pre-processed simply by foo();

emit defined in Qt/qobjectdefs.h (in the flavor of an open source source anyway), for example:

 #ifndef QT_NO_EMIT # define emit #endif 

(Defender defender allows you to use Qt with other frameworks that encounter names using the no_keywords QMake config option.)

Answer 2

After 18 months ... I started with comments in response to @Mat and quickly left the room. So the answer.

IMO emit is neither syntactic sugar nor a simple keyword in the sense that

• It generates code (as described in @Mat above),
• This helps the connect mechanism recognize that it really is a signal and
• It makes your signal part a “larger” system, where signals and responses (slots) can be executed synchronously or asynchronously or in a queue depending on where and how the signal was emitted. This is an extremely useful feature of the signal / slot system.

The entire signal / slot system is a different idiom than a simple function call. I believe this is due to the observer pattern. There is also a big difference between signal and a slot : a signal does not need to be implemented, whereas a slot must be!

You walk along the street and see the house on fire (signal). You dial 911 (connect the fire signal with the 911 response slot). The signal was emitted, and the slot was implemented by the fire department. It may be inaccurate, but you get this idea. Consider the OP example.

Some server objects know how much has been done. Thus, it can simply signal emit progressNotification(...) . It depends on the class that the actual progress bar displays in order to receive this signal and execute it. But how does the connection connect to this signal? Welcome to the Qt Signal / Slot System. Now you can imagine a manager class (usually a kind widget), which consists of a view object and a data calculation object (both are QObjects ), can perform connect (m_myDataEngine, &DataEngine::progressNotification, m_myViewObj, &SimpleView::displayProgress) .

Not to go into the constructive aspects of the manager class, but suffice it to say that this is where the signal / slot system shines. I can focus on developing a very clean architecture for my application. Not always, but often times, I believe that I just emit signals, but I realize slots.

If you can use / call the signal method without emitting it, then this necessarily means that you never needed this function as a signal in the first place.

Answer 3

The second option means that you always know what the function name and function parameters are, and the object that you send it is known for this particular function. These two cases are not always true, so these are the two main reasons why slots and signals came. “under the hood”, the signal and slot mechanism is just a table with pointers to each related function.

Also, look at this pdf, which very clearly explains the nature of the signal and slot mechanism: http://www.elpauer.org/stuff/a_deeper_look_at_signals_and_slots.pdf