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. Returning C++ references from more programming interfaces?
Forum Updated to NodeBB v4.3 + New Features

Returning C++ references from more programming interfaces?

Scheduled Pinned Locked Moved Unsolved General and Desktop
qstandarditemqvectorreferencesapisoftware design
27 Posts 4 Posters 8.3k Views 3 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.
  • E elfring

    You didn't answer

    I suggest to distinguish the update scope and the actor which should trigger the desired change notification (by a specific function call).
    Another software design option would be the use of a corresponding class, wouldn't it?

    Example demo1;
    
    struct notifier
    {
     Example& ex;
     
     notifier(Example& target, int input)
     : ex(target)
     { ex[0] = input; }
     
     ~notifier()
     { ex.valueChanged(); }
    } demo2(demo1, 123);
    
    JKSHJ Offline
    JKSHJ Offline
    JKSH
    Moderators
    wrote on last edited by JKSH
    #21

    @elfring, so you want programmers to replace Code 1 with Code 2; have I understood you correctly?

    //======
    // Code 1
    //======
    Example demo1;
    demo1.setData(123); // Automatically emits valueChanged() immediately
    
    //======
    // Code 2
    //======
    Example demo1;
    notifier demo2(demo1, 123);
    
    // valueChanged() is emitted when demo2 is destroyed
    

    I must say that Code 1 is a much more elegant and intuitive than Code 2.

    Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

    E 1 Reply Last reply
    2
    • JKSHJ JKSH

      @elfring, so you want programmers to replace Code 1 with Code 2; have I understood you correctly?

      //======
      // Code 1
      //======
      Example demo1;
      demo1.setData(123); // Automatically emits valueChanged() immediately
      
      //======
      // Code 2
      //======
      Example demo1;
      notifier demo2(demo1, 123);
      
      // valueChanged() is emitted when demo2 is destroyed
      

      I must say that Code 1 is a much more elegant and intuitive than Code 2.

      E Offline
      E Offline
      elfring
      wrote on last edited by
      #22

      so you want programmers to replace Code 1 with Code 2; …

      Not really. - I suggest to choose between available software design options.

      The standard behaviour of the function “QStandardItem::setData” is generally fine.
      The software situaton might look different if more reference-returning functions from a container class like QVector will be taken into account.
      A need can evolve to call the function “valueChanged” (or “dataChanged”) in a C++ destructor, can't it?

      1 Reply Last reply
      0
      • JKSHJ Offline
        JKSHJ Offline
        JKSH
        Moderators
        wrote on last edited by
        #23

        @elfring said in Returning C++ references from more programming interfaces?:

        so you want programmers to replace Code 1 with Code 2; …

        Not really. - I suggest to choose between available software design options.

        OK.

        The standard behaviour of the function “QStandardItem::setData” is generally fine.

        I'm glad you think it's generally fine.

        The software situaton might look different if more reference-returning functions from a container class like QVector will be taken into account.

        I already explained above why QStandardItem must not provide a reference to is internal data. Do you understand that explanation?

        A need can evolve to call the function “valueChanged” (or “dataChanged”) in a C++ destructor, can't it?

        No, it can't. The signal should be emitted immediately when the data is changed. It should not wait for the destructor of another struct/object.

        Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

        E 1 Reply Last reply
        2
        • JKSHJ JKSH

          @elfring said in Returning C++ references from more programming interfaces?:

          so you want programmers to replace Code 1 with Code 2; …

          Not really. - I suggest to choose between available software design options.

          OK.

          The standard behaviour of the function “QStandardItem::setData” is generally fine.

          I'm glad you think it's generally fine.

          The software situaton might look different if more reference-returning functions from a container class like QVector will be taken into account.

          I already explained above why QStandardItem must not provide a reference to is internal data. Do you understand that explanation?

          A need can evolve to call the function “valueChanged” (or “dataChanged”) in a C++ destructor, can't it?

          No, it can't. The signal should be emitted immediately when the data is changed. It should not wait for the destructor of another struct/object.

          E Offline
          E Offline
          elfring
          wrote on last edited by
          #24

          Do you understand that explanation?

          I can follow software development concerns (which were expressed here) to some degree.

          The signal should be emitted immediately when the data is changed.

          This expectation is also generally fine.

          It should not wait for the destructor of another struct/object.

          The available programming interfaces support to call desired functions in C++ destructors. You can choose under which circumstances such a software design approach will be appropriate.

          JKSHJ 1 Reply Last reply
          0
          • E elfring

            Do you understand that explanation?

            I can follow software development concerns (which were expressed here) to some degree.

            The signal should be emitted immediately when the data is changed.

            This expectation is also generally fine.

            It should not wait for the destructor of another struct/object.

            The available programming interfaces support to call desired functions in C++ destructors. You can choose under which circumstances such a software design approach will be appropriate.

            JKSHJ Offline
            JKSHJ Offline
            JKSH
            Moderators
            wrote on last edited by
            #25

            @elfring said in Returning C++ references from more programming interfaces?:

            I can follow software development concerns (which were expressed here) to some degree.

            That's good. So please address those concerns. For example, why should Qt provide extensions that break encapsulation and increase the risk of errors?

            The signal should be emitted immediately when the data is changed.

            This expectation is also generally fine.

            Good.

            It should not wait for the destructor of another struct/object.

            The available programming interfaces support to call desired functions in C++ destructors. You can choose under which circumstances such a software design approach will be appropriate.

            I cannot see any circumstance where such a software design approach will be appropriate.

            Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

            E 1 Reply Last reply
            0
            • JKSHJ JKSH

              @elfring said in Returning C++ references from more programming interfaces?:

              I can follow software development concerns (which were expressed here) to some degree.

              That's good. So please address those concerns. For example, why should Qt provide extensions that break encapsulation and increase the risk of errors?

              The signal should be emitted immediately when the data is changed.

              This expectation is also generally fine.

              Good.

              It should not wait for the destructor of another struct/object.

              The available programming interfaces support to call desired functions in C++ destructors. You can choose under which circumstances such a software design approach will be appropriate.

              I cannot see any circumstance where such a software design approach will be appropriate.

              E Offline
              E Offline
              elfring
              wrote on last edited by
              #26

              For example, why should Qt provide extensions that break encapsulation and increase the risk of errors?

              I suggest to use algorithms which can work together with container classes at more source code places.

              JKSHJ 1 Reply Last reply
              -1
              • E elfring

                For example, why should Qt provide extensions that break encapsulation and increase the risk of errors?

                I suggest to use algorithms which can work together with container classes at more source code places.

                JKSHJ Offline
                JKSHJ Offline
                JKSH
                Moderators
                wrote on last edited by JKSH
                #27

                @elfring said in Returning C++ references from more programming interfaces?:

                For example, why should Qt provide extensions that break encapsulation and increase the risk of errors?

                I suggest to use algorithms which can work together with container classes at more source code places.

                You did not address any of the concerns. You only added suggestions.

                That is not acceptable. You must only submit ideas/proposals that don't break encapsulation.

                Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                1 Reply Last reply
                3

                • Login

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