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. why QMetaObject::invokeMethod() still construct object when reference is used as input parameter?
QtWS25 Last Chance

why QMetaObject::invokeMethod() still construct object when reference is used as input parameter?

Scheduled Pinned Locked Moved General and Desktop
6 Posts 2 Posters 3.8k Views
  • 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.
  • J Offline
    J Offline
    justDance
    wrote on 25 Jan 2013, 05:42 last edited by
    #1

    I have the following call in worker thread to invoke function call A in main thread. I notice QMetaMethod::invoke() calls QMetaType::construct(), and this function will call class B constructor. And later once it's done, destructor is called in main thread. Why is it even input parameter is reference?

         @ QMetaObject::invokeMethod(this, "A", Qt::QueuedConnection,
            Q_ARG(const B &, b));@
    
    1 Reply Last reply
    0
    • A Offline
      A Offline
      andre
      wrote on 25 Jan 2013, 07:04 last edited by
      #2

      That's how queued signals and slots work. It is unsave to share the same instance of an object between two threads, unless that object makes very strong guarantees about that. Note that the reference part of the parameter is even stripped out of the signature for the signals and slots.

      1 Reply Last reply
      0
      • J Offline
        J Offline
        justDance
        wrote on 4 Feb 2013, 18:35 last edited by
        #3

        Andre, thanks for the info. But how about parameter is a pointer? I have another queued signal slot connection where signal function A and slot function B are using object C pointer as input parameter. I stepped in but seems no constructor is called..

        The code is like:

            @connect(workerThreadObject_ptr, SIGNAL(A(C *)), mainThreadObject_ptr, SLOT(B(C *)));@
        
        1 Reply Last reply
        0
        • A Offline
          A Offline
          andre
          wrote on 4 Feb 2013, 19:41 last edited by
          #4

          Nope, pointer are passed as-is: a pointer.

          1 Reply Last reply
          0
          • J Offline
            J Offline
            justDance
            wrote on 4 Feb 2013, 22:16 last edited by
            #5

            So in this case, it may have safety issue.

            1 Reply Last reply
            0
            • A Offline
              A Offline
              andre
              wrote on 5 Feb 2013, 08:13 last edited by
              #6

              Safety issue? How so?

              No more than if you pass a pointer to an object with a normal method call, and we do that all the time. Of course, you should not pass a pointer to a different thread to an object that is about to be destroyed or run out of scope. If you just want your thread to create an object, and then pass it to another thread, you could consider using a [[doc:QSharedPointer]] instead. You can pass those between threads, and you can be sure the object will not be destroyed before your receiving thread gets the handle to it.

              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