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


  • Moderators

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


  • Moderators

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


  • Moderators

    @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
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.