4. Q_OBJECT macro when using new Qt5 signal/slot syntax

Qt World Summit: Submit your Presentation


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 of QObject derived class:

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

    should i have the Q_OBJECT macro in class declaration?

    0 2 Replies

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

    3

  • @user4592357

    AFAIK yes.

    Q_OBJECT is also required to start the moc process

    4
  • Moderators

    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.

    5 1 Reply

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

    0 1 Reply
  • Moderators

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

    6

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

    0
  • Lifetime Qt Champion

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

    6 1 Reply

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

    3
Log in to reply