Q_SIGNALS vs signals and public Q_SLOTS: vs public slots in class definition

[Szyk]

Hi
I am wonder why I encountered these macros (Q_SINGALS and Q_SLOTS) in Qt Remote Objects examples (maybe they appears earlier in other places). From my point of view "signals" and "public slots" work perfectly. But I realize my field of experience is limited. So I am wonder where these macros would help.
I use F2 (in Qt Createor) to investigate macro code, but no luck, I push F1 to show documentation, no luck, I googled various phrases to investigate meaning of these macors, but no luck.
So maybe some one experienced (or just up to date with this information) can explain to me where Q_SINGALS and Q_SLOTS macros can be useful?!?

thanks and best regards
Szyk Cech

Added after 18 minutes:

Oh! The same question is for Q_EMIT macro vs emit clause...

[high_flyer]

As far as I can tell, the difference is just a syntactical sugar.
The macros are the actual c++ definitions the moc uses to generate the moced classes.
The keywords such 'signal' 'slot' or 'emit' are there to make it more like a feature, like a c++ keyword when typing the code.
You can use the macros instead they do exactly the same.
In fact, I use the macros not the keywords in my code.

This is my personal take on it, I might be wrong.

I am not sure why QtCreator didn't open the macros with F2 for you.
For me it works. (qobjectdefs.h)

[ChristianEhrlicher]

'signals' and 'slots' are no keywords - they are just defines to Q_SIGNALS and Q_SLOTS - see qobjectdefs.h ~line 90:


# define slots Q_SLOTS
# define signals Q_SIGNALS

emit / Q_EMIT is just an empty define - it's just there for readability.

[d_stranz]

'signals' and 'slots' are no keywords

Correct in a C++ sense, but they -are- important and are treated as keywords by MOC, which will use them to generate the actual C++ code that defines the signal methods in the moc_*.cpp files. They probably also play a role in creating automatic connections between widgets defined in the UI file and slots in your C++ code (for example, a QPushButton named "myButton" defined in a UI file and a slot declared as "on_myButton_clicked" in the .h file for the UI). And if you use the old-style connect() with the "SIGNAL()" and "SLOT()" convention, not using the "signal" and "slot" keywords / macros will result in runtime errors because the Qt runtime will be unable to make the connections.

The new Qt connect() versions make it more obvious that signals and slots are just ordinary functions (even lambdas will work as slots). And even though "emit" is a no-op, it's a way of indicating to whoever inherits your code for maintenance (even a future version of yourself) that this is no ordinary function call.