[Interest] Signal/Slot connection fails, even though QMetaObject::activate is called

[Max Paperno]

Happened to stumble upon this clazy check while searching on a completely different issue.
Seems to explain the reasoning pretty well.

https://github.com/KDE/clazy/blob/master/docs/checks/README-connect-3arg-lambda.md

-Max


On 2/15/2020 12:40 AM, Max Paperno wrote:
>
> On 2/14/2020 11:19 PM, Tony Rietwyk wrote (in part):
>> I thought the whole point of the [=] in the lambda is to capture a shallow copy of the state required by the code within the lambda. 
>
> May I ask why you think that, or what you mean?  I can't find any reference to [=] capturing anything about a "state," though  I'm not really sure what you mean by "state."
> What it _can_ capture (and to some extent how) depends on the "reaching scope" but that seems different to what you're saying. I'm re-reading the rather extensive docs
> at cppreference.com... so it's quite possible I'm just missing what you mean.  Other sources I've looked at don't seem to go into as much detail.
>
>> In the shorter overload, I would assume that the context is simply the current thread object.
>
> What do you mean by "current thread object?"  An implicit `this`?
>
>>   Both overloads have the following warning:
>
> No they don't... Looking at doc.qt.io for 5.14 anyway. Only the one with `context` has the part about the context being destroyed (emphasis mine):
>
> "The connection will automatically disconnect if the sender **or the context** is destroyed."
>
> To me this says that you specifically want the connection to be destroyed when the `context` object goes away, in case the sender and receiver/context
> objects aren't the same for some reason. For example I connect a UI element which may somehow have a different lifetime than the `this` object.
> If the lambda code only affects stuff in the sender object (or stuff unrelated to any object), then it probably doesn't matter.
>
> Seems clear that for objects in different threads the sender and receiver/context wouldn't be the same, hence the connection type parameter in that overload.
> But they could also be different regardless of threading, and the connection should be removed when either objects is destroyed.
>
> Of course maybe I have it all wrong... but "seems to work for me" :)
>
> Cheers,
> -Max
>
>
>
> On 2/14/2020 11:19 PM, Tony Rietwyk wrote:
>>
>> On 15/02/2020 7:01 am, Matthew Woehlke wrote:
>>> On 07/02/2020 19.10, Tony Rietwyk wrote:
>>>> Does it work if you don't pass 'this' as the third argument to connect?
>>>> I never use that particular overload of connect. I usually pass the
>>>> lambda as the third argument.
>>> That scares me. The third argument is the context in which the slot
>>> runs, i.e. the "receiver". If your lambda contains any state, not
>>> passing a context risks the slot being called after whatever owns that
>>> state has ceased to exist, which will likely lead to UB. (It also risks
>>> the lambda running in the wrong thread.)
>>>
>>> Basically, if your lambda has *any state at all*, you should *always*
>>> pass a context. The context should be a QObject which owns that state
>>> and whose thread can safely use the state.
>>>
>>> The context should only be omitted if your lambda is stateless, and even
>>> then I'd avoid doing so unless you really need to, or are making a
>>> deliberate choice that no one should "own" the connection.
>>
>> That's strange - I thought the whole point of the [=] in the lambda is to capture a shallow copy of the state required by the code within the lambda.  Whereas [&] copies references to the state variables.  Of course, whether these copies or references work in whatever thread when the code is actually executed is up to you to guarantee - via QSharedPointers or whatever.  I haven't used lambdas across threads - in those cases I've used the receiver/pointer-to-method overload.
>>
>> The third parameter context solely determines which thread's event loop the lambda runs in.  In the shorter overload, I would assume that the context is simply the current thread object. Both overloads have the following warning:
>>
>>     "The connection will automatically disconnect if the sender or the context is destroyed. However, you should take care that any objects used within the functor are still alive when the signal is emitted."
>>
>> In my experience, coding in particular ways "because it scares you" often leads to poor results.  A C++ lambda is basically a temporary object with the copied or referenced state, and a call operator()(...) { /* lambda code */ }.
>>
>> Regards, Tony
>>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest