Do I need to use the Q_OBJECT macro if I only use slots?
-
I have a few classes that are using QWebSocket and it seems I am able to call connect to handle callbacks for connect, close, etc. My debugger says that all is working properly.
If I use the Q_OBJECT macro in my class, than I have to run the MOC compiler in my cmake, which is a pain in the ass when trying to create a lib from my classes and use it in another application, that will make a separate post about.
If I delete the Q_OBJECT macro everything seems to build and run fine without it. So, question is, do I really need it if I am just connecting QWebSocket's signals up to slots?
-
I have a few classes that are using QWebSocket and it seems I am able to call connect to handle callbacks for connect, close, etc. My debugger says that all is working properly.
If I use the Q_OBJECT macro in my class, than I have to run the MOC compiler in my cmake, which is a pain in the ass when trying to create a lib from my classes and use it in another application, that will make a separate post about.
If I delete the Q_OBJECT macro everything seems to build and run fine without it. So, question is, do I really need it if I am just connecting QWebSocket's signals up to slots?
If you want to use signals and slots in your class, you need to use
Q_OBJECTmacro.
You dont have to put it in every single non-QObject class. -
Hi
With the new connect syntax allowing all types of call-ables, it seems you
do not need to add Q_OBJECT to own class as long you are not having custom signals.
At least some fast test would allow a button to call a fucntion in MainWindow without it having
Q_OBJECT.
It also makes sense since the 'new' syntax is pointers to member methods
and not lookup by name as the macro syntax. -
Hi
With the new connect syntax allowing all types of call-ables, it seems you
do not need to add Q_OBJECT to own class as long you are not having custom signals.
At least some fast test would allow a button to call a fucntion in MainWindow without it having
Q_OBJECT.
It also makes sense since the 'new' syntax is pointers to member methods
and not lookup by name as the macro syntax. -
I have a few classes that are using QWebSocket and it seems I am able to call connect to handle callbacks for connect, close, etc. My debugger says that all is working properly.
If I use the Q_OBJECT macro in my class, than I have to run the MOC compiler in my cmake, which is a pain in the ass when trying to create a lib from my classes and use it in another application, that will make a separate post about.
If I delete the Q_OBJECT macro everything seems to build and run fine without it. So, question is, do I really need it if I am just connecting QWebSocket's signals up to slots?
@Fleshbits
I agree with @mrjj qt5 syntax made slots and the slots macro more or less obsolete.You can even connect to lambdas and other stuff you're actually not supposed to connect to in the first place ;)
That said, if your base class is (way down) still QObject based and your derived class is not adding signals you're supposed to add the Macro anyway.
Though, I don't quite remember the reasoning behind it
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@Fleshbits
I agree with @mrjj qt5 syntax made slots and the slots macro more or less obsolete.You can even connect to lambdas and other stuff you're actually not supposed to connect to in the first place ;)
That said, if your base class is (way down) still QObject based and your derived class is not adding signals you're supposed to add the Macro anyway.
Though, I don't quite remember the reasoning behind it
@J-Hilk
That said, if your base class is (way down) still QObject based and your derived class is not adding signals you're supposed to add the Macro anyway.
I thought it is required if your derived class is adding signals, not if it is not adding signals?
Though, I don't quite remember the reasoning behind it
As per https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qobjectdefs.h.html#_M/Q_OBJECT,
Q_OBJECTexpands to add aQMetaObject. You do or do not need it according as you do or do not need this meta-object. -
@Fleshbits
I agree with @mrjj qt5 syntax made slots and the slots macro more or less obsolete.You can even connect to lambdas and other stuff you're actually not supposed to connect to in the first place ;)
That said, if your base class is (way down) still QObject based and your derived class is not adding signals you're supposed to add the Macro anyway.
Though, I don't quite remember the reasoning behind it
@J-Hilk said in Do I need to use the Q_OBJECT macro if I only use slots?:
That said, if your base class is (way down) still QObject based and your derived class is not adding signals you're supposed to add the Macro anyway.
Though, I don't quite remember the reasoning behind it
Q_OBJECTis necessary for QMetaObject stuff to work (likeinherits(),className()etc.).than I have to run the MOC compiler in my cmake, which is a pain in the ass when trying to create a lib
If you do create that thread, please link it here, I'd be interested to see it. In my experience,
set(CMAKE_AUTOMOC ON)works without any hassle at all. -
Well, If I do use Q_OBJECT in my lib, then I run Moc on the header that uses it in my consuming application, that compiles and runs fine.
However, if I do the same in a Qtest project using cmake, I get errors when Moc runs on the lib's header "Parse error at 'std' in fs_...." I can't remember the rest because I changed it back.
So, I tried just deleting the Q_OBJECT in the lib's header, and removing the slots keyword. The connect functions still worked and everything seems to run fine. As a consequence, the Moc is not run in the QTest project and it no longer gives the forementioned error.
Seeing how it works and runs, I just wanted to make sure it is OK to delete it.
Perhaps, I should make a seperate post about the Parse Error with 'std', unless you guys no right off what that's about and it is simple.
-
@J-Hilk said in Do I need to use the Q_OBJECT macro if I only use slots?:
That said, if your base class is (way down) still QObject based and your derived class is not adding signals you're supposed to add the Macro anyway.
Though, I don't quite remember the reasoning behind it
Q_OBJECTis necessary for QMetaObject stuff to work (likeinherits(),className()etc.).than I have to run the MOC compiler in my cmake, which is a pain in the ass when trying to create a lib
If you do create that thread, please link it here, I'd be interested to see it. In my experience,
set(CMAKE_AUTOMOC ON)works without any hassle at all.@sierdzio said in Do I need to use the Q_OBJECT macro if I only use slots?:
Q_OBJECT is necessary for QMetaObject stuff to work (like inherits(), className() etc.).
More important than reflection, though, I'd put
qobject_cast, which does requireQ_OBJECT(i.e. meta-object information).
