Correct syntax to register object reference using qRegisterMetaType?

[JKSH]

@SPlatten said in Correct syntax to register object reference using qRegisterMetaType?:

I'm concerned that the could use more stack and a reference.

There is no need for concern. QJsonObject (and many other Qt datatypes) are implicitly shared so copying is cheap: https://doc.qt.io/qt-5/implicit-sharing.html

I replaced the parameter again with a pointer and this works fine to.

It is easy to cause crashes this way.

How do you manage the lifetime of your object?

[SPlatten]

@JKSH , can you please explain what you mean?

[JKSH]

@SPlatten said in Correct syntax to register object reference using qRegisterMetaType?:

@JKSH , can you please explain what you mean?

Sure thing.

Which part would you like an explanation on? Please have a read through my link first, then let me know which specific parts are unclear.

[kshegunov]

@JKSH said in Correct syntax to register object reference using qRegisterMetaType?:

It is easy to cause crashes this way.

Yeah, what the other guy said ...

@SPlatten said in Correct syntax to register object reference using qRegisterMetaType?:

Only removing the & gets rid of this but then I'm back to the original problem, so how do I get over this?

You don't. You shall not register references as meta-types. They can't ever be such, because they can't be copied.

https://doc.qt.io/qt-5/qmetatype.html#details

Declare new types with Q_DECLARE_METATYPE() to make them available to QVariant and other template-based functions. Call qRegisterMetaType() to make types available to non-template based functions, such as the queued signal and slot connections.

Any class or struct that has a public default constructor, a public copy constructor, and a public destructor can be registered.

[SPlatten]

This is still an issue, I am passing references to signals, type: QJsonObject&, I found this post:
https://stackoverflow.com/questions/23219770/how-to-register-reference-to-qt-containers

However it hasn't helped, I added a call to:

qRegisterMetaType<QJsonObject>("QJsonObject");

I'm still getting:

QObject::connect: Cannot queue arguments of type 'QJsonObject&'

Note I haven't put in the & in the registration as the post on stackoverflow advised against it.

As far as I can see the code is working regardless of the warning, I just don't like messages like this because they suggest something is wrong, can I disable the warning?

Where I have these types the connects have been modified having the last parameter as , Qt::DirectConnection

[SGaist]

Hi,

Don't pass references in parameters. As @JKSH wrote earlier, most of Qt datatypes are implicitly shared so there's really no need to try to go that way.

If you are forcing the Qt::DirectConnection because of that then it means you have a design issue. It's currently pretty rare to have to do that and it also has consequences when doing multithreading.

[SPlatten]

@SGaist , I want to pass by reference because my understanding of passing by reference is that it is far less costly on stack space. A QJsonObject can be very large.

[kshegunov]

@SPlatten said in Correct syntax to register object reference using qRegisterMetaType?:

I want to pass by reference because my understanding of passing by reference is that it is far less costly on stack space. A QJsonObject can be very large.

Your understanding is irrelevant in this case. You were told it isn't possible with a queued connection, and it still isn't, and it is not going to be, no matter how much we argue about it. The warning is there for a reason - to warn you that you have a serious bug in your code. You can either use a direct connection and suffer the inevitable consequences of that, or use const QJsonObject &/QJsonObject for your signal arguments.

[SPlatten]

@kshegunov , I am using const QJsonObject& for my signal arguments, these are working, the only thing that is displayed in the Application Output is the message I've raised. I'm not experience any other problems, crashes or bugs.

[JonB]

@SPlatten
The signal argument type is "OK", insofar as it would work OK with non-cross-thread direct connection connect()s. But the problem is that you are trying to use it when you need a queued connection. That is why you get the error message on the QObject::connect statement.

[SPlatten]

@JonB , thank you, I'll take a look.

[SGaist]

@SPlatten said in Correct syntax to register object reference using qRegisterMetaType?:

@kshegunov , I am using const QJsonObject& for my signal arguments, these are working, the only thing that is displayed in the Application Output is the message I've raised. I'm not experience any other problems, crashes or bugs.

For the slots as well ?

[SPlatten]

@SGaist Of course.

[SPlatten]

Ok, I've now got rid of the warning, by going through all the QObject::connect calls and only using Qt::DirectionConnection where the signal and slot pointers are the same.

[JonB]

@SPlatten
A lot of your questions are about threads. Are your connect()s' senders/receivers never in separate threads?

[SPlatten]

@JonB , not for the ones where I've used Qt::DirectConnection

[Christian Ehrlicher]

@SPlatten said in Correct syntax to register object reference using qRegisterMetaType?:

not for the ones where I've used Qt::DirectConnection

Then it's useless since then Qt::AutoConnection evaluates to Qt::DirectConnection. Specifying a connection type is not needed in most of the cases.

[SPlatten]

@Christian-Ehrlicher , Well that's the only change I'm implemented and now there is no message, so perhaps this is something that needs looking at?

[SGaist]

@SPlatten said in Correct syntax to register object reference using qRegisterMetaType?:

@Christian-Ehrlicher , Well that's the only change I'm implemented and now there is no message, so perhaps this is something that needs looking at?

For that a minimal compilable example would be needed.

[Christian Ehrlicher]

@SPlatten said in Correct syntax to register object reference using qRegisterMetaType?:

so perhaps this is something that needs looking at?

This means that there is a thread context switch somewhere even you tell us it isn't.