QMetaObject::invokeMethod pass custom-type called Twice custom-type's copy constructor...

jsulm

@opengpu said in QMetaObject::invokeMethod pass custom-type called Twice custom-type's copy constructor...:

void slotUpdate(const Data& data)//is this ok???

Yes it is and this is what @SGaist already suggested...

opengpu

@jsulm cool ! so i can always pass-by-ref in Slot, whether it's in one-thread or two-thread?
is there anything should be careful when signal and slot are not in the same thread, and the param is not basic type but custom Stuct/Class?

jsulm

@opengpu As long as a copy is passed between the threads you do not have to worry. But be careful if your structs contain pointers to other data, or if you're passing pointers!

opengpu

class DataWidget : public QWidget
{
Q_OBJECT
public slots:
void slotUpdate(const Data& data)//changed to ref
{
update(data);
}

However, i found these 2 style, by Data or const Data&, they both work, and call Data::Data(const Data& other) 1 time.
bool b = QMetaObject::invokeMethod(g_pMainWin ->GetDataWidget(), "slotUpdate", Qt::QueuedConnection, Q_ARG(Data, data));//why this works while the slot is const Data&
bool b = QMetaObject::invokeMethod(g_pMainWin ->GetDataWidget(), "slotUpdate", Qt::QueuedConnection, Q_ARG(const Data&, data));

opengpu

another question, i found:
//Q_DECLARE_METATYPE(Data);//i can delete this line, and only with qRegisterMetaType that will still work...

//int id = qRegisterMetaType<Data>("Data");
//qRegisterMetaType<Data>("Data");//which should i use, as i pass const Data& in slotUpdate...
qRegisterMetaType<Data>("const Data&");//which should i use, as i pass const Data& in slotUpdate...

jsulm

@opengpu said in QMetaObject::invokeMethod pass custom-type called Twice custom-type's copy constructor...:

why this works while the slot is const

Why should it not? data will be const in the called slot. It doesn't matter whether it is const or not in the caller.

There is no need to register "const Data&". If Data is registered everything else (const, &, *, ...) is simply an "attribute" for an already known type. It is like with the compiler: if the compiler knows what Data is it knows what const Data& is.

J.Hilk

@opengpu said in QMetaObject::invokeMethod pass custom-type called Twice custom-type's copy constructor...:

so i can always pass-by-ref in Slot, whether it's in one-thread or two-thread

be careful that you do not explicitly define the connection as a DirectConnection. I'm not 100% sure, but I think then it will be passed by reference even across threads.

opengpu

@J.Hilk said in QMetaObject::invokeMethod pass custom-type called Twice custom-type's copy constructor...:

e careful that

actually even i use "const Data&" as slot's param, it's still safe while signal and slot are in different slots.
Data::Data(const Data& other) is called 1 time in invokeMethod
bool b = QMetaObject::invokeMethod(g_pMainWin ->GetDataWidget(), "slotUpdate", Qt::QueuedConnection, Q_ARG(const Data&, data));

opengpu

@jsulm "const Data&", i think normally it's not safe to pass-by-reference across threads, right?

VRonin

@opengpu said in QMetaObject::invokeMethod pass custom-type called Twice custom-type's copy constructor...:

i think normally it's not safe to pass-by-reference across threads, right?

Depends who you ask. The chair of the C++ standard committee is of the opinion that as STL uses const as implying thread safety* the entire language should conform to that convention. In that case using cons& as argument is safe even across threads. On the other hand it's a jungle out there and it's very easy to break that convention so I would not bet my life on thread safety of const references

*source: https://herbsutter.com/2013/01/01/video-you-dont-know-const-and-mutable/

jsulm

@opengpu said in QMetaObject::invokeMethod pass custom-type called Twice custom-type's copy constructor...:

it's not safe to pass-by-reference across threads, right?

@SGaist already explained in this thread that the parameter is copied when using queued connection between threads, so it IS safe...