Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. ":connect' error - "multiple definition..." ?
Forum Updated to NodeBB v4.3 + New Features

":connect' error - "multiple definition..." ?

Scheduled Pinned Locked Moved Solved General and Desktop
25 Posts 7 Posters 6.5k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Axel SpoerlA Offline
    Axel SpoerlA Offline
    Axel Spoerl
    Moderators
    wrote on last edited by
    #21

    @SimonSchroeder said in ":connect' error - "multiple definition..." ?:

    Q_ASSUME?

    Maybe I wasn't clear in my proposal to wrap QObject::connect() into Q_ASSUME().
    This is for debugging and analyzing, if a connection was successful at all.
    It's not recommended for production code, however.
    Q_ASSUME() instructs the compiler to assume, that the wrapped condition is true. That's for optimizing purposes. The condition itself can be optimized out, even if that's not always the case. It remains the compiler's decision.
    Q_ASSERT() will always kick in debug builds and is completely optimized out on production. In a debug build, Q_ASSUME becomes a Q_ASSERT, so they are treated identically.

    Having said that, the safe way to assert a connection is to read it's return value into a variable, debug it and act on it. Connections should be designed such, that they always work. Once the plumbing is done, all the wrappers can go out. They create unnecessary overhead in stable code. That's why QObject::connect() is not marked nodiscard, like other functions that do not allow their return value to be ignored.

    Software Engineer
    The Qt Company, Oslo

    1 Reply Last reply
    1
    • A Offline
      A Offline
      Anonymous_Banned275
      wrote on last edited by
      #22

      I have added some"B@W" so we can see the compiler / linker actual output.
      It still shows that the pointers match.

      BT_ChatServer::BT_ChatServer(QObject *)
      & line "84"
      DEBUG connect void BT_SPP_CA_MainWindow::Connect_MainServer() @ line "1399" this BT_SPP_CA_MainWindow(0x558ce48df8f0, name="BT_SPP_CA_MainWindow")
      DEBUG connect void BT_SPP_CA_MainWindow::Connect_MainServer() @ line "1400" server BT_ChatServer(0x558ce4df7170)
      !!!!!!!!!!!!!!!!!!!!server BT_ChatServer(0x558ce4df7170)
      DEBUG connect void BT_ChatServer::startServer(const QBluetoothAddress &) @ line "109" this BT_ChatServer(0x558ce4df7170)

      "emit NewMessage(text)"
      void BT_ChatServer::PostMessage(const QString)

      As far as Q_ASSUME goes - it does check the syntax , not the actual function of the "connect" .
      This is helpful.

      I do understated there may be alternatives to accomplish passing messages between objects, but my goal is to find out WHY this does not work.
      ( The BT_ChatServer is a member of BT_SPP_CA_MainWindow )

      If I have a multiple and WRONG "connect" would it still do something , even if incorrect ?
      It is (remotely) possible that the "new" syntax does not works BETWEEN objects ?
      ( I just cannot believe this "passing messages", was never tried by some other coder ....)

      Let's keep in focus, it does not matter what / where the error is, I just want to resolve it,
      putting the blame on something / somebody IS NOT my goal.

      .

      1 Reply Last reply
      0
      • A Offline
        A Offline
        Anonymous_Banned275
        wrote on last edited by
        #23

        Maybe Q_ASSUME will do more...

        I went back to the "old style" too,
        The old style complains about missing parameter.

        Then my usage of Q_ASSUME is also wrong - I need to fix that and see if it will help to locate the problem...

        ..and yes,, I hand two instances of "server" , but either one should pass the test message....

        QObject::connect: No such signal BT_ChatServer::&BT_ChatServer().NewMessage() in bt_spp_ca_mainwindow.cpp:1466
        QObject::connect:  (receiver name: 'BT_SPP_CA_MainWindow')
        ASSERT failure in Q_ASSUME(): "Assumption in Q_ASSUME("connect (server,SIGNAL(&BT_ChatServer().NewMessage()), this,SLOT(&BT_SPP_CA_MainWindow().PostMessage()) );") was not correct", file bt_spp_ca_mainwindow.cpp, line 1470
        11:16:58: /mnt/07b7c3f8-0efb-45ab-8df8-2a468771de1f/PROJECTS/BT_JAN13_/Qt-5.15.2/widgets/mainwindows/mdi/mdi crashed.
        
        
                    Q_ASSUME(
                            connect
                                    (server,SIGNAL(&BT_ChatServer().NewMessage()),
                                     this,SLOT(&BT_SPP_CA_MainWindow().PostMessage())
                                     );
        
                            );
        
        
                   //Q_ASSUME(connect(this, &BT_SPP_CA_MainWindow::NewMessage, this, &BT_SPP_CA_MainWindow::PostMessage));
        
                    Q_ASSUME(connect(server,&BT_ChatServer::NewMessage,this,&BT_SPP_CA_MainWindow::PostMessage));
        
                    qDebug() <<"DEBUG connect " << Q_FUNC_INFO << "@ line " << QString::number(__LINE__) << " server  " << server;
        
        1 Reply Last reply
        0
        • A Offline
          A Offline
          Anonymous_Banned275
          wrote on last edited by
          #24

          more debugging....
          Added another class member , "standard" Qt Designer Form class with single TEST button emitting test message.

          SUCCESS The message gets passed to the "parent" using "connect"....

          What is puzzling - the debug outputs are in reverse sequence...

          So - I must have a wrong "connect " somewhere.... in my original code....

          1478edf2-5f82-4789-a5ef-ed8d5d34d267-image.png

          1 Reply Last reply
          0
          • A Offline
            A Offline
            Anonymous_Banned275
            wrote on last edited by
            #25

            SOLVED

            Eureka !!
            The original QT example code has multiple instances of ChatServer and no "delete".

            Now a minor curiosity question remains:
            if the test code emits TWO messages , why do I get only ONE "postmessage " ?

            void BT_ChatServer::PostMessage(const QString)
            "\n\t TASK Run \nvoid BT_ChatServer::PostMessage(const QString)\n !!!! REMOTE !!!! TEST MESSAGE "
            void BT_ChatServer::PostMessage(const QString)
            "\n\t TASK Run \nvoid BT_ChatServer::PostMessage(const QString)\n !!!! REMOTE !!!! TEST MESSAGE "
            void BT_SPP_CA_MainWindow::PostMessage(const QString)
            "\n\t TASK Run \nvoid BT_SPP_CA_MainWindow::PostMessage(const QString)\n !!!! REMOTE !!!! TEST MESSAGE "

            1 Reply Last reply
            0

            • Login

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups
            • Search
            • Get Qt Extensions
            • Unsolved