qRegisterMetaType- reference as argument in connect throwing run time error

[prasad_N]

I have typedef in my code & I wanted to use this in connect function so I register this new data type.

typedef std::vector< std::vector<int> > myData;
qRegisterMetaType<myData>("myData");

typedef std::vector< std::vector<int> > myData;
qRegisterMetaType<myData>("myData");

To copy to clipboard, switch view to plain text mode 

connect(this, SIGNAL(startFetchingRecordsInThread(myData&)), this, SLOT(startFetchingRecords(myData&)));   //is throwing below error

connect(this, SIGNAL(startFetchingRecordsInThread(myData&)), this, SLOT(startFetchingRecords(myData&)));   //is throwing below error

To copy to clipboard, switch view to plain text mode 

QObject::connect: Cannot queue arguments of type 'myData&'
(Make sure 'myData&' is registered using qRegisterMetaType().)

When I remove & (pass by reference) from argument

SIGNAL(startFetchingRecordsInThread(myData))

Its working fine.
Is there some thing I missed here ??

[d_stranz]

Have you implemented the operators required for serializing your metatype?

[anda_skoa]

Reference arguments cannot be used with queued connection.

After all a queued connection transports the arguments via copying them into an event and sending the event to the receiver object.

Cheers,
_

[prasad_N]

Have you implemented the operators required for serializing your metatype?

Sorry I am not sure with this, What are the operators I need to implement & In which class I have to implement them ??

[d_stranz]

QMetaType and qRegisterMetaTypeStreamOperators():

If we want the stream operators operator<<() and operator>>() to work on QVariant objects that store custom types, the custom type must provide operator<<() and operator>>() operators.

[prasad_N]

Reference arguments cannot be used with queued connection.

After all a queued connection transports the arguments via copying them into an event and sending the event to the receiver object.

Cheers,
_

Changing my connect function to Qt:irectConnection worked out, I hope it will not create any problem as this is going to start my thread.

---

Added after 4 minutes:

QMetaType and qRegisterMetaTypeStreamOperators():

My new data type is just typedefed one

typedef std::vector< std::vector<int> > myData;

, Sorry but I did not get how implementing this operators related to my problem.

[anda_skoa]

Changing my connect function to Qt:irectConnection worked out, I hope it will not create any problem as this is going to start my thread.

Is the receiver objects in a different thread?
If so, is the slot properly taking care of the concurrent access if there is one?
Why have references at all?

Cheers,
_

[prasad_N]

Is the receiver objects in a different thread?
If so, is the slot properly taking care of the concurrent access if there is one?
Why have references at all?

Cheers,
_

Yes its in different thread. I am fetching few records from data base & playing with it main thread besides I am launching a thread parallel which fetches all the data from data base in thread.
Why reference: I need the data in my class (from where I created my thread & start) so I am sending a vector of vector as reference & In thread it fetches all the data once my thread finishes I have all the data in my class, I am using reference here just to avoid one more finished signal with the data as argument (to avoid copy).

[anda_skoa]

In your example both sender and receiver are "this" so if you don't want to copy, why not just have the data as a member?

In any case, if you really must allocate the data structure on the main thread, then hand it to the secondary thread, you might want to do that via pointers, the reference cannot be stored, so even with a direct connection it will only be available in the slot, not in any code executed by the other thread.

Still a very strange pattern, maybe some more code would clarify what you are actually trying to do?

Cheers,
_

[prasad_N]

In your example both sender and receiver are "this" so if you don't want to copy, why not just have the data as a member?
Still a very strange pattern, maybe some more code would clarify what you are actually trying to do?_

There was a typo in my question (i directly copied from my project code & while changing it I messed up) & here is the simplified code

Ex: 
 
typedef std::vector< std::vector<int> > myData;
qRegisterMetaType<myData>("myData");
 
class testClass  // I want to pass this obj as reference
{
public:
    int a;
};
 
 
//In my main thread (myclass) : QThread m_thread  & workerClass m_worker are the class members & below is constructor code
 
connect(&m_thread, SIGNAL(started()), this, SLOT(startThread()));
connect(this, SIGNAL(startMyThread(myData&)), &m_worker, SLOT(heavyWork(myData&)));
m_worker.moveToThread(&m_thread);
m_thread.start();
 
void myclass::startThread()
{
     myData obj;
 
     emit startMyThread(obj);
}

Ex: 

typedef std::vector< std::vector<int> > myData;
qRegisterMetaType<myData>("myData");

class testClass  // I want to pass this obj as reference
{
public:
    int a;
};


//In my main thread (myclass) : QThread m_thread  & workerClass m_worker are the class members & below is constructor code

connect(&m_thread, SIGNAL(started()), this, SLOT(startThread()));
connect(this, SIGNAL(startMyThread(myData&)), &m_worker, SLOT(heavyWork(myData&)));
m_worker.moveToThread(&m_thread);
m_thread.start();

void myclass::startThread()
{
     myData obj;
    
     emit startMyThread(obj);
}

To copy to clipboard, switch view to plain text mode 

So here I am getting same error:

QObject::connect: Cannot queue arguments of type 'myData&'
(Make sure 'myData&' is registered using qRegisterMetaType().)

when I make it direct connection (connect(this, SIGNAL(startMyThread(myData&)), &m_worker, SLOT(heavyWork(myData&)), Qt:irectConnection) , the slot is getting executed in the main thread.

i am just looking for a way to pass reference to the thread. i can do it with the pointer as you suggested, But as I am using vector of vector, using pointer to the vector of vector may complicate or confuse or may lead to some memory leaks which I don't want & exactly for the same reason we have reference.

[d_stranz]

Sorry but I did not get how implementing this operators related to my problem.

You may not need them; however, if your data needs to marshalled across a thread boundary you might need them if they aren't already defined for std:: vector<>

[anda_skoa]

i am just looking for a way to pass reference to the thread. i can do it with the pointer as you suggested, But as I am using vector of vector, using pointer to the vector of vector may complicate or confuse or may lead to some memory leaks which I don't want & exactly for the same reason we have reference.

Well, right now, if it would work, you would have the thread access a destroyed object.
I would consider that even worse than a memory leak :-)

Cheers,
_

[prasad_N]

Well, right now, if it would work, you would have the thread access a destroyed object.
I would consider that even worse than a memory leak :-)_

Any how passing reference to thread is not working now, is there a particular reason for this ?
Can we request Qt guys to have this feature in future versions ??

[anda_skoa]

Any how passing reference to thread is not working now, is there a particular reason for this ?

Passing a reference is possible, just not via a queued connection.

A queued connection needs to transfer the data via an event, so each signal argument needs to be stored in a QVariant and then put into an event that is sent to the receiver via the receiver thread's event loop.
There the arguments are extraced again and the slot is called.

Aside from references being very in appropriate due to implicit life time assumption (easily leading to destroy before use like in your code), they cannot be stored (neither in a QVariant but also not in a normal member variable).

Can we request Qt guys to have this feature in future versions ??

What feature?
To store a reference like a pointer? That you would have to take up with the C++ standard comittee.

Cheers,
_

[prasad_N]

you would have the thread access a destroyed object._

you are referring to below function I think & myData obj; is a class member in my actual code & It never gets destructed before thread finishes. again this is due to writing some code on fly sorry for that.

void myclass::startThread()
{
     myData obj;   //this is class member in actual code & never gets destructed before thread finishes, I just wanted to show the reference variable problem here so I just didn't care this 
 
     emit startMyThread(obj);
}

void myclass::startThread()
{
     myData obj;   //this is class member in actual code & never gets destructed before thread finishes, I just wanted to show the reference variable problem here so I just didn't care this 
 
     emit startMyThread(obj);
}

To copy to clipboard, switch view to plain text mode 

Passing a reference is possible, just not via a queued connection._

So what connect should I use, Direct connection making slot to execute in main thread. I think other connections more or less same as these 2 connections except unique connection.

What feature?
To store a reference like a pointer? That you would have to take up with the C++ standard comittee._

passing reference to thread when It is queued connection if there is no other way.

[Lesiok]

myData obj is destroyed immediately after emiting signal. Slot in another thread is run in the future when the object referenced by reference no longer exists.

[prasad_N]

myData obj is destroyed immediately after emiting signal. Slot in another thread is run in the future when the object referenced by reference no longer exists.

That is what I clarified in the above reply, myData obj is actually class member of myclass in my original code. It never gets destroyed before worker thread finishes its work.

[anda_skoa]

you are referring to below function I think & myData obj; is a class member in my actual code & It never gets destructed before thread finishes. again this is due to writing some code on fly sorry for that.

Then you should probably not have used a local variable definition.

So what connect should I use, Direct connection making slot to execute in main thread. I think other connections more or less same as these 2 connections except unique connection.

It depends on your requirements.
If you want the slot to execute in the context of the emitter thread, use a direct connection.
If you want to use the signal/slot bridge as a mean to conveniently copy data between threads, use a queued connection.

passing reference to thread when It is queued connection if there is no other way.

I wouldn't get my hope up. If the C++ Standard committee wanted to allow assigment of reference variables, that would have been possible a long time ago, especially since that has always been possible for pointers.

I.e. if C programmers want to refer to the same object from two different variables (aliasing), they use pointers.
C++ programmers can also use pointers and can use references for the special case where the alias can be initialized with the address of the object, e.g. passing a reference to a constructor, storing it in a reference member.

Cheers,
_

[d_stranz]

Then you should probably not have used a local variable definition.

@prasad_N:
Or at least written it as a commented-out line, with an explanation that "obj" is a class member variable. How are we to understand that when you write it as you did, you weren't posting your actual code? A lot of the discussion here was based on your incorrect posting, and it could have been avoided if you had posted the actual code in the first place.

C++ programmers can also use pointers and can use references for the special case where the alias can be initialized with the address of the object, e.g. passing a reference to a constructor, storing it in a reference member.

And this has the added benefit over storing a pointer member variable in that you are absolutely assured that the member variable is a valid reference to an object instance, whereas anything can be assigned to a pointer member, including nothing.

[prasad_N]

A lot of the discussion here was based on your incorrect posting, and it could have been avoided if you had posted the actual code in the first place.

There was a mistake & people are over emphasizing on that rather than a actual question, Anyhow I will take care from next time while posting.

It depends on your requirements.
If you want the slot to execute in the context of the emitter thread, use a direct connection.
If you want to use the signal/slot bridge as a mean to conveniently copy data between threads, use a queued connection.
_

None of them are not my requirements. As per my requirement & Replay's from you guys I think there is no solution for this at least for now (passing reference across threads if it it is queued connection).