[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