The drawback of signal/slots ?

[VRonin]

@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

[VincentLiu]

@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

[SGaist]

@VincentLiu Yes, that's a valid use case.

[VincentLiu]

@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?

[VRonin]

@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) use const Mat& mat instead of Mat& mat for safety

[VincentLiu]

@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?

[VRonin]

This is strange, could you post the entire error?

[VincentLiu]

@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 ?

[VRonin]

if vector is std::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

[stryga42]

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.

[vladstelmahovsky]

@VRonin in case of Qt:QueuedConnection is will be passed by value anyway

[VRonin]

@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

[kshegunov]

@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.

[stryga42]

@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?

[kshegunov]

@VincentLiu @stryga42

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).

[VincentLiu]

@kshegunov

Thanks. Actually I did what you displayed, but it works until I use Qt:DirectConnection.

[kshegunov]

@VincentLiu said in The drawback of signal/slots ?:

Actually I did what you displayed

Not according to the snippet you posted. Bear in mind:

qRegisterMetaType<Mat>();

and

qRegisterMetaType<Mat>("Mat");

are different things in principle.

[VincentLiu]

@kshegunov Really !!! Thanks, I'll try it