[Development] How qAsConst and qExchange lead to qNN

A. Pönitz apoenitz at t-online.de
Fri Nov 11 00:01:14 CET 2022


On Thu, Nov 10, 2022 at 03:55:39PM +0000, Marc Mutz via Development wrote:
> Hi Ivan,
> 
> On 10.11.22 11:03, Ivan Solovev via Development wrote:
> > I wonder how your NOI-everywhere suggestion will work with the 
> > signal/slot connections? Specially for the case when 
> > Qt::QueuedConnection is used (explicitly or implicitly).
> 
> That's a very good question, thanks.
> 
> As a first reaction, three things come to mind:
> 
> 1. It doesn't, obviously. If you emit signals, any signal argument must
>     be owning, or QueuedConnection cannot be used. Given that C++20
>     requires us to mark up views and non-owning ranges (enable_view,
>     enable_borrowed_range), I'm confident that we could detect attempts
>     to create such connections at compile- or, latest, at run-time, and
>     refuse them, or, since we need to serialize the arguments into a
>     QMetaCallEvent, anyway, also lifetime-pin, either by holding a weak
>     reference to the source object or by storing the data in the event in
>     an owning container.
> 
> 2. QML and QProperty do not appear to require passing the new value in a
>     NOTIFY signals's parameter, so just not passing the argument is an
>     option, too (but doesn't work with QueuedConnection, either).
> 
> 3. Finally, the kinds of types I'm primarily thinking of in the context
>     of NOI are not Q_OBJECTS. It remains to be seen in which form or
>     shape co-routine-based reactive programming will complement or even
>     substitute signal/slots in the future.
> 
> So, to summarize, I'd say that NOI works well with signal/slot, too, 
> with the exception of QueuedConnection, where we have several options 
> for work-arounds.

In the context of Qt, a library, that is used by code in unrelated
projects, which may or may not use QueuedConnection on each signal,
in fact for each individual connect, I cannot even remotely think
of a non-owning interface unless this is somehow "owning in disguise",
i.e. offer spans as parameters but effectively stashs away a deep copy
in a safe place.

Could you give a hint on what these several options for work-arounds
may be?

Andre'


More information about the Development mailing list