Q_OBJECT macro when using new Qt5 signal/slot syntax

[user4592357]

if i have defined only this (and no other signals/slots and also i don't need qobject_cast) in ctor of QObject derived class:

connect(this, &QPushButton::clicked, [this]
{
		// do work
});

should i have the Q_OBJECT macro in class declaration?

[Taz742]

@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

[koahnig]

@user4592357

AFAIK yes.

Q_OBJECT is also required to start the moc process

[kkoehne]

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.

[Taz742]

@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

[kshegunov]

@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 macro

Actually 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.

[user4592357]

say i'm making a shared library where i have this file (there are no signals/slots etc.)
if i'm ALWAYS using Q_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.

[Christian Ehrlicher]

@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...

[koahnig]

@Christian-Ehrlicher

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.pro

QT -= 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.