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?



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



  • @user4592357

    AFAIK yes.

    Q_OBJECT is also required to start the moc process


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



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


  • Qt Champions 2017

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



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


  • Qt Champions 2018

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



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


Log in to reply