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. reply->deleteLater in slot conditions
Qt 6.11 is out! See what's new in the release blog

reply->deleteLater in slot conditions

Scheduled Pinned Locked Moved Solved General and Desktop
7 Posts 4 Posters 1.4k Views 2 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.
  • M Offline
    M Offline
    Mr Gisa
    wrote on last edited by
    #1

    I have a slot that I connected with QNetworkAccessManager and in that slot I have a few conditions that I made with the content of the request, in one of them I use the return in order to stop the continuation of the slot so I was wondering, if I have a condition like this:

    if(something) {
        return;
    }
    

    do I have to call reply->deleteLater() in each condition that returns?

    if(something) {
        reply->deleteLater();
        return;
    }
    
    reply->deleteLater();
    

    I know if might sound a silly question, but I really don't know if I need that.

    1 Reply Last reply
    0
    • Christian EhrlicherC Online
      Christian EhrlicherC Online
      Christian Ehrlicher
      Lifetime Qt Champion
      wrote on last edited by
      #2

      The documentation of QNetworkAccessManager is very clear here:
      Note: After the request has finished, it is the responsibility of the user to delete the QNetworkReply object at an appropriate time. Do not directly delete it inside the slot connected to finished(). You can use the deleteLater() function.

      See http://doc.qt.io/qt-5/qnetworkaccessmanager.html#details

      Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
      Visit the Qt Academy at https://academy.qt.io/catalog

      1 Reply Last reply
      1
      • M Offline
        M Offline
        Mr Gisa
        wrote on last edited by Mr Gisa
        #3

        I know that, but that is not my question here actually, but if I have multiple if conditions in my finished reply slot, if I do have to be calling reply->deleteLater in each condition that needs to return and stop the execution. Or I can call reply->deleteLater right at the top once.

        Example :
        0_1526038165694_89e1e325-9655-416c-8f4d-fdb85ee47e9b-image.png

        JonBJ 1 Reply Last reply
        0
        • M Mr Gisa

          I know that, but that is not my question here actually, but if I have multiple if conditions in my finished reply slot, if I do have to be calling reply->deleteLater in each condition that needs to return and stop the execution. Or I can call reply->deleteLater right at the top once.

          Example :
          0_1526038165694_89e1e325-9655-416c-8f4d-fdb85ee47e9b-image.png

          JonBJ Online
          JonBJ Online
          JonB
          wrote on last edited by
          #4

          @Mr-Gisa
          https://stackoverflow.com/questions/4888189/how-delete-and-deletelater-works-with-regards-to-signals-and-slots-in-qt

          The deleteLater adds an event that will be handled in the main loop when control gets there.

          mrjjM 1 Reply Last reply
          1
          • JonBJ JonB

            @Mr-Gisa
            https://stackoverflow.com/questions/4888189/how-delete-and-deletelater-works-with-regards-to-signals-and-slots-in-qt

            The deleteLater adds an event that will be handled in the main loop when control gets there.

            mrjjM Offline
            mrjjM Offline
            mrjj
            Lifetime Qt Champion
            wrote on last edited by mrjj
            #5

            @JonB
            That is also what i assume. event loop is busy with current function so it should be safe
            to deleteLater at top since nothing will happened before function ends.
            Im just wondering if it will work in all use cases/always.

            JonBJ 1 Reply Last reply
            0
            • mrjjM mrjj

              @JonB
              That is also what i assume. event loop is busy with current function so it should be safe
              to deleteLater at top since nothing will happened before function ends.
              Im just wondering if it will work in all use cases/always.

              JonBJ Online
              JonBJ Online
              JonB
              wrote on last edited by JonB
              #6

              @mrjj
              Well, the OP asked:

              Or I can call reply->deleteLater right at the top once.

              [to cut down on his coding] So he can safely do that at the top instead of the bottom providing the slot code does not allow main event loop to run, if that's what he wants to do. But if there is a chance that, say, at a later date someone might alter that code it might be dangerous. There are probably some C++ contructs which allow a piece of code to be run on function return (e.g. some scoped destructor)? In C# or Python I'd probably wrap in a try ... finally...

              mrjjM 1 Reply Last reply
              0
              • JonBJ JonB

                @mrjj
                Well, the OP asked:

                Or I can call reply->deleteLater right at the top once.

                [to cut down on his coding] So he can safely do that at the top instead of the bottom providing the slot code does not allow main event loop to run, if that's what he wants to do. But if there is a chance that, say, at a later date someone might alter that code it might be dangerous. There are probably some C++ contructs which allow a piece of code to be run on function return (e.g. some scoped destructor)? In C# or Python I'd probably wrap in a try ... finally...

                mrjjM Offline
                mrjjM Offline
                mrjj
                Lifetime Qt Champion
                wrote on last edited by
                #7

                @JonB
                Ok we have the same ideas about it then :)
                one QApplication::processEvents to ruin it all ;)

                I suggested to use QScopedPointer with QScopedPointerDeleteLater
                to be sure.

                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