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. Pure virtual interface for signal and slots leads to amibigiuos connect method
Forum Updated to NodeBB v4.3 + New Features

Pure virtual interface for signal and slots leads to amibigiuos connect method

Scheduled Pinned Locked Moved Solved General and Desktop
19 Posts 7 Posters 1.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.
  • S SiGa

    @jeremy_k
    With the pure virtual interface I intend to force the inheriting class to implement/have these.
    With "Right" I mean that I can connect the child signals&slots and they are correctly triggered.
    Is such a mechanism even possible with moc generation?
    Does moc generate for each *.cpp files, or does it respect inheritance?

    jeremy_kJ Offline
    jeremy_kJ Offline
    jeremy_k
    wrote on last edited by
    #10

    @SiGa said in Pure virtual interface for signal and slots leads to amibigiuos connect method:

    @jeremy_k
    With the pure virtual interface I intend to force the inheriting class to implement/have these.

    moc implements signals based on their signature. If it did support virtual signals, it would be creating the same implementation for each derived class.
    The code is essentially:

    void signal(Types... args) {
       for (auto slot: connected_slots)
          slot(args);
    }
    

    What's the point of an identical override of that?

    With "Right" I mean that I can connect the child signals&slots and they are correctly triggered.

    Right and correct are synonyms in this situation. To avoid a circular discussion, please use code examples.

    Is such a mechanism even possible with moc generation?

    With my current understanding of the problem, I'm going to say 'no', with the caveat that I don't think it is necessary.

    Does moc generate for each *.cpp files, or does it respect inheritance?

    moc is a relatively simplistic code generator. Given a file (.cpp or .h makes no difference) that mentions a signal or slot section, it generates code for signals and lookup tables for both. If moc never sees the file, no code is generated. If it finds no relevant keywords, no code is generated.

    Asking a question about code? http://eel.is/iso-c++/testcase/

    1 Reply Last reply
    2
    • jeremy_kJ jeremy_k

      @JonB said in Pure virtual interface for signal and slots leads to amibigiuos connect method:

      @SiGa

      class IServerCommand : public QObject
      
      class LiveTab : public QWidget, IServerCommand
      

      You are dual-inheriting from QObject (QWidget obviously inherits it too), I thought that was not permitted (moc can't handle it for signals/slots)?

      It's the C++ diamond inheritance issue rather than, or perhaps in addition to moc's limitation.

      S Offline
      S Offline
      SiGa
      wrote on last edited by
      #11

      @jeremy_k
      The versions of QObject::connect that take a sender object are static. The code might as well invoke it that way.

      Do you mean that with specific calls to connect this might work?

      jeremy_kJ 1 Reply Last reply
      0
      • S SiGa

        @jeremy_k
        The versions of QObject::connect that take a sender object are static. The code might as well invoke it that way.

        Do you mean that with specific calls to connect this might work?

        jeremy_kJ Offline
        jeremy_kJ Offline
        jeremy_k
        wrote on last edited by
        #12

        @SiGa said in Pure virtual interface for signal and slots leads to amibigiuos connect method:

        @jeremy_k
        The versions of QObject::connect that take a sender object are static. The code might as well invoke it that way.

        Do you mean that with specific calls to connect this might work?

        I only use QObject::connect(&sender, &SenderClass::signal, ...). I never use
        &SenderClass::connect(...), or any other superclass of SenderClass.

        Asking a question about code? http://eel.is/iso-c++/testcase/

        1 Reply Last reply
        0
        • A Offline
          A Offline
          Asperamanca
          wrote on last edited by Asperamanca
          #13

          How about composition instead of inheritance?

          class AbstractServerCommand : public QObject
          {
            Q_OBJECT
          public:
            virtual void ~AbstractServerCommand ( ) = default;
          
          signals:
            void requestServerCommandConnection();
          public slots:
            void handleServerCommandResponse(); // Calls handleServerCommandResponseImpl
          private:
            void handleServerCommandResponseImpl() = 0;
          };
          
          class IServerCommandProvider
          {
          public:
            virtual void ~IServerCommandProvider() = default;
          
            virtual AbstractServerCommand& getServerCommandInterface() = 0;
          };
          
          class LiveTabServerResponse : public AbstractServerCommand 
          {
            Q_OBJECT
          public:
            ~LiveTabServerResponse() override = default;
          private:
            void handleServerCommandResponseImpl() override;
          };
          
          class LiveTab : public QWidget, IServerCommandProvider
          {
            Q_OBJECT
          public:
            ~LiveTab() override = default;
          
            // Co-variant overload
            LiveTabServerResponse& getServerCommandInterface() override; // Returns reference to m_ServerCommandInterface
          
          private:
            LiveTabServerResponse m_ServerCommandInterface;
          

          Now you should have everything covered:

          • If you derive from IServerCommandProvider, it forces you to provide access to a AbstractServerCommand
          • The AbstractServerCommand defines the signal, and allows you to do a custom implementation of the slot
          • If you need the same implementation for AbstractServerCommand in different classes, you only need to write it once
          • If LiveTabServerResponse needs to call something in LiveTab, there are multiple ways to solve this. One way is to pass a std::function to the constructor of LiveTabServerResponse that e.g. should be called whenever the slot is called.
          jeremy_kJ S 2 Replies Last reply
          1
          • A Asperamanca

            How about composition instead of inheritance?

            class AbstractServerCommand : public QObject
            {
              Q_OBJECT
            public:
              virtual void ~AbstractServerCommand ( ) = default;
            
            signals:
              void requestServerCommandConnection();
            public slots:
              void handleServerCommandResponse(); // Calls handleServerCommandResponseImpl
            private:
              void handleServerCommandResponseImpl() = 0;
            };
            
            class IServerCommandProvider
            {
            public:
              virtual void ~IServerCommandProvider() = default;
            
              virtual AbstractServerCommand& getServerCommandInterface() = 0;
            };
            
            class LiveTabServerResponse : public AbstractServerCommand 
            {
              Q_OBJECT
            public:
              ~LiveTabServerResponse() override = default;
            private:
              void handleServerCommandResponseImpl() override;
            };
            
            class LiveTab : public QWidget, IServerCommandProvider
            {
              Q_OBJECT
            public:
              ~LiveTab() override = default;
            
              // Co-variant overload
              LiveTabServerResponse& getServerCommandInterface() override; // Returns reference to m_ServerCommandInterface
            
            private:
              LiveTabServerResponse m_ServerCommandInterface;
            

            Now you should have everything covered:

            • If you derive from IServerCommandProvider, it forces you to provide access to a AbstractServerCommand
            • The AbstractServerCommand defines the signal, and allows you to do a custom implementation of the slot
            • If you need the same implementation for AbstractServerCommand in different classes, you only need to write it once
            • If LiveTabServerResponse needs to call something in LiveTab, there are multiple ways to solve this. One way is to pass a std::function to the constructor of LiveTabServerResponse that e.g. should be called whenever the slot is called.
            jeremy_kJ Offline
            jeremy_kJ Offline
            jeremy_k
            wrote on last edited by jeremy_k
            #14

            @Asperamanca said in Pure virtual interface for signal and slots leads to amibigiuos connect method:

            public slots:
              void handleServerCommandResponse(); // Calls handleServerCommandResponseImpl
            private:
              void handleServerCommandResponseImpl() = 0;
            

            This is an unnecessary indirection. Virtual slots are fine. They are not implemented by moc.
            Qt uses virtual slots within public apis.
            https://doc.qt.io/qt-6/qabstractitemview.html#reset

            void QAbstractItemView::reset() [virtual slot]
            

            Asking a question about code? http://eel.is/iso-c++/testcase/

            1 Reply Last reply
            0
            • S Offline
              S Offline
              SimonSchroeder
              wrote on last edited by
              #15

              I don't see a way to get signals into IServerCommand. To solve the diamond problem (from the point-of-view of C++, not necessarily Qt) the common parent (i.e. QObject) would need to virtual. I expect you do not want to change (and recompile) the Qt source so that QWidget uses virtual inheritance. This would leave the solution proposed by @Asperamanca.

              If there were a way to do this, the signals of IServerCommand don't have to be virtual. moc will implement them for you and subclasses will just inherit their implementation. The implementation would not change for subclasses anyway. You could still connect using the name of the subclass.

              You have to be careful with connecting to your slots of IServerCommand and their subclasses. Under no circumstance should you write

              QObject::connect(request, &Request::responseAvailable, command, &IServerCommand::handleServerCommandResponse);
              

              If you write it like this C++ will not respect your virtual keyword (since you explicitly specified the implementation of which class to use). I hate to say this, but here you should use the old connect syntax (this is what it was meant for):

              QObject::connect(request, SIGNAL(responseAvailable()), command, SLOT(handleServerCommandResponse()));
              

              If you want to stick to the new connect syntax, you are back to the other approach suggested by @Asperamanca:

              class IServerCommand : public QObject
              {
                //...
              public slots:
                void handleServerCommandResponse(); // calls handleServerCommandResponseImpl
              private:
                virtual void handleServerCommandResponseImpl() = 0;
              }
              

              In any case class LiveTab : public QWidget, IServerCommand is not a good idea as it is mixing concerns. A widget should do widget stuff and a command should do command stuff. The widget can know about the command and display its results. Think of the good old MVC pattern (though with Qt it is quite usable to mix View and Controller, but the Model should be kept separate).

              A 1 Reply Last reply
              3
              • S SimonSchroeder

                I don't see a way to get signals into IServerCommand. To solve the diamond problem (from the point-of-view of C++, not necessarily Qt) the common parent (i.e. QObject) would need to virtual. I expect you do not want to change (and recompile) the Qt source so that QWidget uses virtual inheritance. This would leave the solution proposed by @Asperamanca.

                If there were a way to do this, the signals of IServerCommand don't have to be virtual. moc will implement them for you and subclasses will just inherit their implementation. The implementation would not change for subclasses anyway. You could still connect using the name of the subclass.

                You have to be careful with connecting to your slots of IServerCommand and their subclasses. Under no circumstance should you write

                QObject::connect(request, &Request::responseAvailable, command, &IServerCommand::handleServerCommandResponse);
                

                If you write it like this C++ will not respect your virtual keyword (since you explicitly specified the implementation of which class to use). I hate to say this, but here you should use the old connect syntax (this is what it was meant for):

                QObject::connect(request, SIGNAL(responseAvailable()), command, SLOT(handleServerCommandResponse()));
                

                If you want to stick to the new connect syntax, you are back to the other approach suggested by @Asperamanca:

                class IServerCommand : public QObject
                {
                  //...
                public slots:
                  void handleServerCommandResponse(); // calls handleServerCommandResponseImpl
                private:
                  virtual void handleServerCommandResponseImpl() = 0;
                }
                

                In any case class LiveTab : public QWidget, IServerCommand is not a good idea as it is mixing concerns. A widget should do widget stuff and a command should do command stuff. The widget can know about the command and display its results. Think of the good old MVC pattern (though with Qt it is quite usable to mix View and Controller, but the Model should be kept separate).

                A Offline
                A Offline
                Asperamanca
                wrote on last edited by
                #16

                @SimonSchroeder Thanks, you said all I wanted to say here, in more detail

                1 Reply Last reply
                0
                • A Asperamanca

                  How about composition instead of inheritance?

                  class AbstractServerCommand : public QObject
                  {
                    Q_OBJECT
                  public:
                    virtual void ~AbstractServerCommand ( ) = default;
                  
                  signals:
                    void requestServerCommandConnection();
                  public slots:
                    void handleServerCommandResponse(); // Calls handleServerCommandResponseImpl
                  private:
                    void handleServerCommandResponseImpl() = 0;
                  };
                  
                  class IServerCommandProvider
                  {
                  public:
                    virtual void ~IServerCommandProvider() = default;
                  
                    virtual AbstractServerCommand& getServerCommandInterface() = 0;
                  };
                  
                  class LiveTabServerResponse : public AbstractServerCommand 
                  {
                    Q_OBJECT
                  public:
                    ~LiveTabServerResponse() override = default;
                  private:
                    void handleServerCommandResponseImpl() override;
                  };
                  
                  class LiveTab : public QWidget, IServerCommandProvider
                  {
                    Q_OBJECT
                  public:
                    ~LiveTab() override = default;
                  
                    // Co-variant overload
                    LiveTabServerResponse& getServerCommandInterface() override; // Returns reference to m_ServerCommandInterface
                  
                  private:
                    LiveTabServerResponse m_ServerCommandInterface;
                  

                  Now you should have everything covered:

                  • If you derive from IServerCommandProvider, it forces you to provide access to a AbstractServerCommand
                  • The AbstractServerCommand defines the signal, and allows you to do a custom implementation of the slot
                  • If you need the same implementation for AbstractServerCommand in different classes, you only need to write it once
                  • If LiveTabServerResponse needs to call something in LiveTab, there are multiple ways to solve this. One way is to pass a std::function to the constructor of LiveTabServerResponse that e.g. should be called whenever the slot is called.
                  S Offline
                  S Offline
                  SiGa
                  wrote on last edited by SiGa
                  #17

                  Thank you all for the suggestions.
                  In the end I implemented it as a QObject, which becomes a child of the parent, which contains the interface.
                  My mainframe then finds all instances of my ServerInterface through the QMetaMethod System, and connects everything accordingly
                  Surely not the purest C++ solution to this problem, but it seemed most logical to me.

                  I don't know which reply I should mark as answer since I did not try out the suggestion from @Asperamanca

                  A J.HilkJ 2 Replies Last reply
                  0
                  • S SiGa

                    Thank you all for the suggestions.
                    In the end I implemented it as a QObject, which becomes a child of the parent, which contains the interface.
                    My mainframe then finds all instances of my ServerInterface through the QMetaMethod System, and connects everything accordingly
                    Surely not the purest C++ solution to this problem, but it seemed most logical to me.

                    I don't know which reply I should mark as answer since I did not try out the suggestion from @Asperamanca

                    A Offline
                    A Offline
                    Asperamanca
                    wrote on last edited by
                    #18

                    @SiGa There usually is more than one answer :-)

                    1 Reply Last reply
                    1
                    • S SiGa

                      Thank you all for the suggestions.
                      In the end I implemented it as a QObject, which becomes a child of the parent, which contains the interface.
                      My mainframe then finds all instances of my ServerInterface through the QMetaMethod System, and connects everything accordingly
                      Surely not the purest C++ solution to this problem, but it seemed most logical to me.

                      I don't know which reply I should mark as answer since I did not try out the suggestion from @Asperamanca

                      J.HilkJ Offline
                      J.HilkJ Offline
                      J.Hilk
                      Moderators
                      wrote on last edited by
                      #19

                      @SiGa you can just use the topic tools and set the whole topic to solved


                      Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                      Q: What's that?
                      A: It's blue light.
                      Q: What does it do?
                      A: It turns blue.

                      1 Reply Last reply
                      1
                      • S SiGa has marked this topic as solved on

                      • Login

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