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. [SOLVED] Do qt's classes own objects passed by arguments?
Forum Updated to NodeBB v4.3 + New Features

[SOLVED] Do qt's classes own objects passed by arguments?

Scheduled Pinned Locked Moved General and Desktop
9 Posts 4 Posters 1.9k Views 1 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.
  • T3STYT Offline
    T3STYT Offline
    T3STY
    wrote on last edited by
    #1

    Most classes documentation will put a note when an object passed by argument is going to be owned by the calling class. But many others don't. For example, if have the next code:
    @
    QWidget theWidget;
    QPalette * colors = new QPalette;
    // ...
    myWidget.setPalette(*colors);
    @
    Does now "theWidget" own the "colors" instance of QPalette? Or does setPalette() create a copy of the palette passed by argument?
    More in general, how does Qt behave with objects passed in arguments when not specified in the docs ?

    1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #2

      Hi,

      Don't allocate your QPalette on the heap, there's no need for that. In fact if you want to play with QPalette you should do something like:

      @
      QPalette colors = myWidget.palette();
      // modify colors
      myWidget.setPalette(colors);
      @

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0
      • T3STYT Offline
        T3STYT Offline
        T3STY
        wrote on last edited by
        #3

        The problem is that I have a class that needs to store internally a QPalette. If I don't do that I should make public some internal widgets or I should create get/set methods.

        Anyway, that's not why I posted. I'm actually interested in the ownership behavior of Qt. C++'s behavior is to copy arguments; that is, anything passed in argument is copied before a function/method is called, including pointers and references. In the case of pointers and references though there is no way to predict whether a call will bind the pointed object to the calling function/method, or not. So I often find myself wondering what will happen after a call...

        1 Reply Last reply
        0
        • N Offline
          N Offline
          norisezp
          wrote on last edited by
          #4

          I would also like an answer to this.

          1 Reply Last reply
          0
          • JKSHJ Online
            JKSHJ Online
            JKSH
            Moderators
            wrote on last edited by
            #5

            When you pass by value, a new copy is created and passed to the function (this applies to all C++, not just Qt). So, the function cannot possibly take ownership of original.

            It doesn't make sense to take ownership of a reference, since the original is often stack-allocated. (You must not manually destroy a stack-allocated object)

            Qt methods usually take ownership of QObjects passed into them (and this is always passed by pointer), unless the documentation states otherwise.

            See also: "Identity vs. Value":http://doc.qt.io/qt-5/object.html#qt-objects-identity-vs-value. In Qt, value objects are always passed by value; identity objects are always passed by pointer and the function usually takes ownership of them unless the documentation states otherwise.

            [quote author="T3STY" date="1424990719"]The problem is that I have a class that needs to store internally a QPalette.[/quote]Then store a QPalette, not a QPalette*.

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

            1 Reply Last reply
            0
            • T3STYT Offline
              T3STYT Offline
              T3STY
              wrote on last edited by
              #6

              That was an awesome explanation, thanks!

              1 Reply Last reply
              0
              • N Offline
                N Offline
                norisezp
                wrote on last edited by
                #7

                So, I never want to pass a pointer to stack-allocated object? That does make sense, since the stack object only exists during execution of the current function, and will be deleted when it returns. But, this is an error that I could commit, and Qt does not detect it, right?

                1 Reply Last reply
                0
                • T3STYT Offline
                  T3STYT Offline
                  T3STY
                  wrote on last edited by
                  #8

                  It's C++ that does not detect the "error". Actually, to C++ it only looks like you passed a pointer to some object in memory - whether it's heap or stack it doesn't matter. Passing pointers or references to stack allocated objects is allowed, even if not desirable in most cases. Please also note that with stack allocated objects you usually pass references (&) instead of pointers (*).
                  However, you deciding to pass a pointer to a stack allocated object is your decision only. When accessing an object removed from stack it can cause all sorts of problems (your program could crash with no apparent reason and unexplainable error messages). But it is up to you to turn it into an error or a flawless execution.

                  bottom line of the story: if an object is stack allocated, try not to use any pointers to it.

                  1 Reply Last reply
                  0
                  • N Offline
                    N Offline
                    norisezp
                    wrote on last edited by
                    #9

                    Thanks, I'll consider myself answered and not try to probe further if Qt catches a stack pointer or not.

                    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