Unsolved Q_OBJECT macro when using new Qt5 signal/slot syntax
-
if i have defined only this (and no other signals/slots and also i don't need
qobject_cast
) in ctor ofQObject
derived class:connect(this, &QPushButton::clicked, [this] { // do work });
should i have the
Q_OBJECT
macro in class declaration? -
@user4592357 said in Q_OBJECT macro when using new Qt5 signal/slot syntax:
should i have the Q_OBJECT macro in class declaration?
Yes.
@user4592357 said in Q_OBJECT macro when using new Qt5 signal/slot syntax:
connect(this, &QPushButton::clicked, [this]
{
// do work
});Here it seems that this is (connect(this, &QPushButton)) a QPushButton derived class.
http://www.qtcentre.org/threads/19216-Deriving-From-QPushButton
-
-
Because you're using a lambda as a slot, I don't think that you absolutely need a Q_OBJECT macro for this to work.
Anyhow, it's good practice to use Q_OBJECT in all classes deriving from QObject.
-
@kkoehne said in Q_OBJECT macro when using new Qt5 signal/slot syntax:
I don't think that you absolutely need a Q_OBJECT macro for this to work.
Its wrong.
@kkoehne said in Q_OBJECT macro when using new Qt5 signal/slot syntax:
Because you're using a lambda as a slot
And what?
you cannot emit someSignal() if you dont have Q_OBJECT macro
-
@Taz742 said in Q_OBJECT macro when using new Qt5 signal/slot syntax:
Its wrong.
No, he is not.
And what?
you cannot emit someSignal() if you dont have Q_OBJECT macroActually you can, you just can't have your own signals. In any case you can subscribe to a signal that's fired from whatever part of the (Qt) code without the
Q_OBJECT
macro, as long as you use the pointer-to-member syntax.@user4592357 said in Q_OBJECT macro when using new Qt5 signal/slot syntax:
should i have the Q_OBJECT macro in class declaration?
Even if you're not required to in this case, yes, you should put it there; for various reasons - consistency, clarity of code, preventing future errors if you start using the meta-object system for something, etc.
-
say i'm making a shared library where i have this file (there are no signals/slots etc.)
if i'm ALWAYS usingQ_OBJECT
, i'd add it to this class.
that means for my shlib i also need to generate an .obj file from the .moc file, which of course increases my shlib size. -
@user4592357 said in Q_OBJECT macro when using new Qt5 signal/slot syntax:
which of course increases my shlib size.
Simple main.cpp with class which has Q_OBJECT:
-rwxr-xr-x 1 chehrlic users 32520 31. Jul 20:03 qtbug_18520
and without:
-rwxr-xr-x 1 chehrlic users 31920 31. Jul 20:04 qtbug_18520
and this is with debug symbols. After stripping it is 19024 to 18992
So you really want us to say that this matters in a significant way by the fact that someone who's using your lib can't use qobject_cast<> for your classes...
-
Thanks for going through this.
Here are some results on windows 10 64 bit with MinGW 32 bit for Qt 5.4.2
Verzeichnis von r:\build-MemSizeCheck-Desktop_Qt_5_4_2_MinGW_32bit2-Debug\debug 01.08.2018 12:26 324'751 MemSizeCheck.exe Verzeichnis von r:\build-MemSizeCheck-Desktop_Qt_5_4_2_MinGW_32bit2-Debug\debug 01.08.2018 12:31 465'155 MemSizeCheck.exe Verzeichnis von r:\build-MemSizeCheck-Desktop_Qt_5_4_2_MinGW_32bit2-Release\release 01.08.2018 12:27 17'920 MemSizeCheck.exe Verzeichnis von r:\build-MemSizeCheck-Desktop_Qt_5_4_2_MinGW_32bit2-Release\release 01.08.2018 12:29 18'432 MemSizeCheck.exe
Numbers are based on this code generated mostly with Qt templates.
MemSizeCheck.proQT -= gui CONFIG += c++11 console CONFIG -= app_bundle # The following define makes your compiler emit warnings if you use # any feature of Qt which as been marked deprecated (the exact warnings # depend on your compiler). Please consult the documentation of the # deprecated API in order to know how to port your code away from it. DEFINES += QT_DEPRECATED_WARNINGS # You can also make your code fail to compile if you use deprecated APIs. # In order to do so, uncomment the following line. # You can also select to disable deprecated APIs only up to a certain version of Qt. #DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000 # disables all the APIs deprecated before Qt 6.0.0 SOURCES += \ main.cpp \ FakeClass.cpp # Default rules for deployment. qnx: target.path = /tmp/$${TARGET}/bin else: unix:!android: target.path = /opt/$${TARGET}/bin !isEmpty(target.path): INSTALLS += target HEADERS += \ FakeClass.h
main.cpp
#include <QCoreApplication> #include "FakeClass.h" int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); return a.exec(); }
FakeClass.cpp
#include "FakeClass.h" FakeClass::FakeClass(QObject *ptr) : QObject ( ptr ) { }
FakeClass.h
#ifndef FAKECLASS_H #define FAKECLASS_H #include <QObject> class FakeClass : private QObject { Q_OBJECT public: explicit FakeClass( QObject *ptr = 0 ); }; #endif // FAKECLASS_H
Debug compilations have significant larger executables, but in release mode this is really marginal.