Unsolved The drawback of signal/slots ?
-
Hi everyone,
We know that signal/slots is one of the significant features in QT. Every time we tend to use it, we have to emit a signal from A and the receiver B capture the signal using slots. After processing, B emit a signal with the processed result and A capture it using its slots.
// In A class: emit AtoBSignal(param1, param2, ...); // In B class: void AtoBSlot(param1, parm2, ...) { // do something Result resultObj = .....; emit BtoASignal(resultObj); } // In A class: Result resultObj; void BtoASlot(Result resultObj) { // get the result and do something later this->resultObj = resultObj; }
Is it the best way using signal/slot ? I mean, two passes (foward and back) to complete one communication. Comparing to general class instances, we can simply invoke and get the result in one sentence such as:
resultObj = obj.query(param1, param2, ...)
Please correct me if I am wrong. If it is correct, then it causes several class variables such as resultObj depicted above since the resultObj might be used later in different function. Is it the burden by signal/slot scheme or actually I miss some information about it ? Thanks ~~
-
I think in the code above the main burden is the pass-by-value in your signal and slots rather than the mechanism itself. convert the arguments to const references in both signals and slots, or even better, rvalue references if Result supports move semantic in any meaningful way
-
Hi,
To add to @VRonin, can you describe your use case more completely ?
From a quick read, it looks like you are trying to replace direct calls with signals and slots everywhere even when not needed.
-
@VRonin Thanks for your opinion. Is using const reference or rvalue better than pass by value a general sense in c++ or it is a feature of signal/slots ? Actually I have tried to use const reference such as Mat& based on OpenCV but in vain. I failed to register the type Mat& using qRegisterType(). In your memory, are the 3rd party types or custom types easy to register? I have no idea whether I have wrong code or it is actually a limitation in qRegisterType(). One of the code snippet:
Q_DECLARE_METATYPE(Mat&) int main(int argc, char *argv[]) { qRegisterMetaType<Mat&>("Mat&"); }
Do I make any mistake? Thanks
-
@SGaist Thanks for your reply. I usually need signal/slots when the objects are in different threads. For example, one in GUI thread and the other in another thread reading frame from the camera. I want to send the image read to the GUI. Signal/slots is a must in this case, is that correct ???
-
@VincentLiu said in The drawback of signal/slots ?:
using const reference or rvalue better than pass by value a general sense in c++ or it is a feature of signal/slots ?
It's general in C++ but, given you are not familiar with them I'd not meddle with move semantics for now, stick to the const reference
qRegisterMetaType<Mat&>("Mat&");
You have to register the type, not the reference, also you need to declare the metatype first with Q_DECLAREMETATYPE
-
@VRonin
Actually I have already done something like:Q_DECLARE_METATYPE(Mat) int main(int argc, char *argv[]) { qRegisterMetaType<Mat>("Mat"); ..... }
Then I can successfully emit signal with Mat but not Mat&. Is it what you mean? If so, do I miss anything else? Thanks
-
@VincentLiu Yes, that's a valid use case.
-
@SGaist Hi, should I be able to use something like
emit AtoBSignal(Mat& mat);
after I registered the type Mat like the code snippet above?
-
@VincentLiu No, but just because the syntax is wrong. you declare the signal with:
signals: void AtoBSignal(Mat& mat);
and emit it with:
Mat mat; // do something with mat emit AtoBSignal(mat);
P.S.
if you do not wish to edit the original object inside the slot (as is normally the case) useconst Mat& mat
instead ofMat& mat
for safety -
@VRonin Sorry that I didn't check the code snippet. The real one is just what you displayed. But the error message still says that I should register the type "Mat&". Any else is important?
-
This is strange, could you post the entire error?
-
@VRonin Hi, below is the signal and slot:
void bgVecReadySignal(vector<Mat>& bgVec); void bgVecReadySlot(vector<Mat>& bgVec);
And in main.cpp:
int main(int argc, char *argv[]) { qDebug() << "Invoked main.cpp - " << QThread::currentThreadId(); qRegisterMetaType<vector<Mat>>("vector<Mat>"); qRegisterMetaType<Mat>("Mat"); ..... }
And error message shows:
QObject::connect: Cannot queue arguments of type 'vector<Mat>&' (Make sure 'vector<Mat>&' is registered using qRegisterMetaType().)
Did I miss anything? Thanks
I just found that using Qt::DirectConnection works fine. However, is it a right way to do so ?
-
if
vector
isstd::vector
then it's because it's not natively supported by QVariant (i.e. you have to register the vector with the meta object system) alternatively you can use QVector which is already supported -
Hi all, do you really think that passing by reference is fine for an asynchronous signal? Both sender and receiver could change the content but with undefined sequence. My guess is that Qt refuses to pass the reference if it is going to use an asyc signal, as it is the default for thread-spanning signals.
Synchronous signals are more or less simple function calls, so there it would be OK.
I guess this is also the major reason why Qt does not support return values in the signal/slot system. -
@VRonin in case of Qt:QueuedConnection is will be passed by value anyway
-
@stryga42 said in The drawback of signal/slots ?:
Both sender and receiver could change the content
If 2 threads are accessing on read/write the same variable you have to handle it manually, set up a mutex of some sort. It's not as easy as passing a reference
-
@stryga42 said in The drawback of signal/slots ?:
Hi all, do you really think that passing by reference is fine for an asynchronous signal?
It is fine because you get a reference to a copy of the original object (hence the need to do
qRegisterMetaType<>()
.Both sender and receiver could change the content but with undefined sequence.
Only with direct connections, which isn't the default accross threads.
My guess is that Qt refuses to pass the reference if it is going to use an asyc signal, as it is the default for thread-spanning signals.
No. You must register the type with the meta-type system, so Qt knows how to copy it when the slot-invocation event is placed in the receiving thread's event loop.
Synchronous signals are more or less simple function calls, so there it would be OK.
It wouldn't because you need to guard the reference manually from both threads.
I guess this is also the major reason why Qt does not support return values in the signal/slot system.
The major reason is because when queuing a slot for execution (as with default signal-slot connection across threads) there's no meaning to return values. You can't know when the slot will be invoked, and even if you could you will already have far surpassed the point where you can obtain a return value in the emitting thread.
-
@kshegunov
Sure, return values for queued connection are quite useless., I tried to say that.
But the original question is then still open; maybe the class Mat has no copy constructor available? -
qRegisterMetaType<Mat>(); qRegisterMetaType<vector<Mat>>();
should fix it, provided there's also:
Q_DECLARE_METATYPE(Mat) Q_DECLARE_METATYPE(vector<Mat>)
somewhere in the header(s).