Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Special Interest Groups
  3. C++ Gurus
  4. Second guessing the compiler?
Forum Updated to NodeBB v4.3 + New Features

Second guessing the compiler?

Scheduled Pinned Locked Moved Solved C++ Gurus
11 Posts 5 Posters 723 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.
  • fcarneyF Offline
    fcarneyF Offline
    fcarney
    wrote on last edited by
    #1

    I have code like this:

    void function(QPointF p){
        const float x = p.x();
        const float y = p.y();
        const float w = p.width();
        const float h = p.height();    
    
        // use vars for whatever
    }
    

    Am I second guessing the compiler here? Will the compiler optimize the function call out after the first call if I use p.x() in more than one place?

    C++ is a perfectly valid school of magic.

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

      @fcarney said in Second guessing the compiler?:

      Will the compiler optimize the function call out after the first call if I use p.x() in more than one place?

      You mean when you call function() with the same point again?

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

      fcarneyF 1 Reply Last reply
      0
      • Christian EhrlicherC Christian Ehrlicher

        @fcarney said in Second guessing the compiler?:

        Will the compiler optimize the function call out after the first call if I use p.x() in more than one place?

        You mean when you call function() with the same point again?

        fcarneyF Offline
        fcarneyF Offline
        fcarney
        wrote on last edited by
        #3

        @Christian-Ehrlicher said in Second guessing the compiler?:

        You mean when you call function() with the same point again?

        Yes, I am wondering if the other calls get optimized out as long as the object does not change.

        C++ is a perfectly valid school of magic.

        JonBJ Christian EhrlicherC kshegunovK 3 Replies Last reply
        0
        • fcarneyF fcarney

          @Christian-Ehrlicher said in Second guessing the compiler?:

          You mean when you call function() with the same point again?

          Yes, I am wondering if the other calls get optimized out as long as the object does not change.

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

          @fcarney
          One thing I think will certainly be true: it will depend on compiler and code optimization flags. Are you expecting the same behaviour from msvc -O2 and gcc -g?

          You will not know for sure what it might or might not do. If you don't want p.x() to be evaluated again, push its result to a variable.

          And if you really mean will code be generated which recognises whether the incoming parameter's value has changed across calls to the function, I think you can assume that is unlikely. The optimizations in the compiled code will be over multiple calls to p.x() within a function, where it can see p has not been changed by logic. And furthermore, because p.x() is a function call, not just a reference, it will only optimize calls out at all if it knows from the definition that there are no side-effects/extra code, and it's a clever optimizer :)

          What does the declaration of QPointF::x() look like anyway, is it an inline?

          1 Reply Last reply
          1
          • fcarneyF fcarney

            @Christian-Ehrlicher said in Second guessing the compiler?:

            You mean when you call function() with the same point again?

            Yes, I am wondering if the other calls get optimized out as long as the object does not change.

            Christian EhrlicherC Online
            Christian EhrlicherC Online
            Christian Ehrlicher
            Lifetime Qt Champion
            wrote on last edited by
            #5

            @fcarney said in Second guessing the compiler?:

            I am wondering if the other calls get optimized out as long as the object does not change.

            Since you did not post the full code - no
            Your current code will be completely removed by the optimizer since it does nothing.

            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
            0
            • fcarneyF fcarney

              @Christian-Ehrlicher said in Second guessing the compiler?:

              You mean when you call function() with the same point again?

              Yes, I am wondering if the other calls get optimized out as long as the object does not change.

              kshegunovK Offline
              kshegunovK Offline
              kshegunov
              Moderators
              wrote on last edited by
              #6

              @fcarney said in Second guessing the compiler?:

              Yes, I am wondering if the other calls get optimized out as long as the object does not change.

              No, not as a rule. But compiler optimizers are pretty complex, so my advice is - write it as it is most obvious/convenient for you and leave the compiler to do its magic; a.k.a. have love and faith in your friendly compiler writer, not doubt. ;)

              @JonB said in Second guessing the compiler?:

              If you don't want p.x() to be evaluated again, push its result to a variable.

              Wrong. Putting something into a variable means nothing to the compiler. It can reorder and reorganize the code as it likes as long as it can prove the result is correct.

              What does the declaration of QPointF::x() look like anyway, is it an inline?

              Yes, it's inline.

              Read and abide by the Qt Code of Conduct

              JonBJ 1 Reply Last reply
              2
              • kshegunovK kshegunov

                @fcarney said in Second guessing the compiler?:

                Yes, I am wondering if the other calls get optimized out as long as the object does not change.

                No, not as a rule. But compiler optimizers are pretty complex, so my advice is - write it as it is most obvious/convenient for you and leave the compiler to do its magic; a.k.a. have love and faith in your friendly compiler writer, not doubt. ;)

                @JonB said in Second guessing the compiler?:

                If you don't want p.x() to be evaluated again, push its result to a variable.

                Wrong. Putting something into a variable means nothing to the compiler. It can reorder and reorganize the code as it likes as long as it can prove the result is correct.

                What does the declaration of QPointF::x() look like anyway, is it an inline?

                Yes, it's inline.

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

                @kshegunov said in Second guessing the compiler?:

                @JonB said in Second guessing the compiler?:

                If you don't want p.x() to be evaluated again, push its result to a variable.

                Wrong. Putting something into a variable means nothing to the compiler. It can reorder and reorganize the code as it likes as long as it can prove the result is correct.

                Not fair! Mine was intended as practical advice. What you can be sure of, from a validated compiler, is that it will not re-call a function which does/might/could have side-effects if you assign to a variable. Whereas you cannot say the same for sure of second-guessing whether the compiler might or might not save a call if you do not store to a variable and re-use the function call.

                Yes, it's inline.

                Then if it's nice and small like just returning a member, the whole discussion for the OP of whether to bother storing into variables is moot.... (Again, practical rather than theoretical observation.)

                kshegunovK 1 Reply Last reply
                0
                • JonBJ JonB

                  @kshegunov said in Second guessing the compiler?:

                  @JonB said in Second guessing the compiler?:

                  If you don't want p.x() to be evaluated again, push its result to a variable.

                  Wrong. Putting something into a variable means nothing to the compiler. It can reorder and reorganize the code as it likes as long as it can prove the result is correct.

                  Not fair! Mine was intended as practical advice. What you can be sure of, from a validated compiler, is that it will not re-call a function which does/might/could have side-effects if you assign to a variable. Whereas you cannot say the same for sure of second-guessing whether the compiler might or might not save a call if you do not store to a variable and re-use the function call.

                  Yes, it's inline.

                  Then if it's nice and small like just returning a member, the whole discussion for the OP of whether to bother storing into variables is moot.... (Again, practical rather than theoretical observation.)

                  kshegunovK Offline
                  kshegunovK Offline
                  kshegunov
                  Moderators
                  wrote on last edited by
                  #8

                  @JonB said in Second guessing the compiler?:

                  What you can be sure of, from a validated compiler, is that it will not re-call a function which does/might/could have side-effects if you assign to variable.

                  Fair argument, I agree.

                  Then if it's nice and small like just returning a member

                  Yes, it is. ... and I know you know we both know where this is all going to end ... ;D

                  Read and abide by the Qt Code of Conduct

                  1 Reply Last reply
                  2
                  • fcarneyF Offline
                    fcarneyF Offline
                    fcarney
                    wrote on last edited by fcarney
                    #9

                    One thing I am considering is whether or not the call could be to a shared object (threading). Is this case no, but as things get more and more parallel it may cause a change in coding style to change to be more defensive in this regard. Like making sure to take a snapshot of a whole object to prevent desynchronization of values (like x and y are related mathmatically). In that case QPointF temp = p; would protect against that.

                    I didn't want to be creating boilerplate for no good reason. I do like the syntax better for just working with a local x variable. I don't like the extra object.func() syntax in a calculation. The const qualifier is defensive in this case as well. To prevent me from changing something because of autocomplete. Which has happened recently.

                    Edit:
                    Yes I realize I am working with a copy passed to the function. I am thinking of when using a reference or pointer that could be passed in for the potential desynchronization issues.

                    C++ is a perfectly valid school of magic.

                    kshegunovK 1 Reply Last reply
                    0
                    • fcarneyF fcarney

                      One thing I am considering is whether or not the call could be to a shared object (threading). Is this case no, but as things get more and more parallel it may cause a change in coding style to change to be more defensive in this regard. Like making sure to take a snapshot of a whole object to prevent desynchronization of values (like x and y are related mathmatically). In that case QPointF temp = p; would protect against that.

                      I didn't want to be creating boilerplate for no good reason. I do like the syntax better for just working with a local x variable. I don't like the extra object.func() syntax in a calculation. The const qualifier is defensive in this case as well. To prevent me from changing something because of autocomplete. Which has happened recently.

                      Edit:
                      Yes I realize I am working with a copy passed to the function. I am thinking of when using a reference or pointer that could be passed in for the potential desynchronization issues.

                      kshegunovK Offline
                      kshegunovK Offline
                      kshegunov
                      Moderators
                      wrote on last edited by kshegunov
                      #10

                      @fcarney said in Second guessing the compiler?:

                      Like making sure to take a snapshot of a whole object to prevent desynchronization of values (like x and y are related mathmatically). In that case QPointF temp = p; would protect against that.

                      This is what you'd usually do - use reentrant objects, i.e. copy instead of sharing the data. The same you do for ints, floats and whatever. You'd want to share the data only if:

                      1. It's too big and the malice to performance from copying it is unacceptable. Delaying the copying is fine however (see. QSharedData and QSharedDataPointer)
                      2. It's a global state which can't be avoided, then you have 2 options:
                        • serialize the access (think mutexes and semaphores)
                        • impose some restrictions on the user code so that you ensure you initialize and use the object(s) in a specific manner (e.g. QApplication)

                      I didn't want to be creating boilerplate for no good reason. I do like the syntax better for just working with a local x variable. I don't like the extra object.func() syntax in a calculation. The const qualifier is defensive in this case as well. To prevent me from changing something because of autocomplete. Which has happened recently.

                      That's all in line with what I said - do your code as good as you imagine it and trust the compiler do the right thing with that.

                      Yes I realize I am working with a copy passed to the function. I am thinking of when using a reference or pointer that could be passed in for the potential desynchronization issues.

                      If you're working with references then you almost universally need to make sure two things happen:

                      1. You can handle the pointer itself safely, if that's needed (e.g. passing a pointer from one thread to the next). This is actually the main (and only) purpose of the shared pointer idiom (QSharedPointer).
                      2. You serialize access to the data fields when done from different threads (mutexes and semaphores again).
                        Important note: This is about the object, not the pointer! So it's completely independent from 1!

                      Read and abide by the Qt Code of Conduct

                      1 Reply Last reply
                      4
                      • JKSHJ Offline
                        JKSHJ Offline
                        JKSH
                        Moderators
                        wrote on last edited by
                        #11

                        Useful reading on the topic of sharing data (including between threads): https://doc.qt.io/qt-5/implicit-sharing.html

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

                        1 Reply Last reply
                        4

                        • Login

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