[Development] Changes to QObject::connect and other functor-taking API implementations

[Volker Hilsheimer]

On 3 May 2023, at 19:32, A. Pönitz <apoenitz at t-online.de> wrote:

On Wed, May 03, 2023 at 03:21:40PM +0200, Giuseppe D'Angelo via Development wrote:
Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto:

What started as an attempt to provide a few building blocks for making it easier to build asynchronous APIs taking any kind of callable (like QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a longer journey to the core.

[1]https://codereview.qt-project.org/c/qt/qtbase/+/470341
[2]https://codereview.qt-project.org/c/qt/qtbase/+/475168

A general problem here is whether we can provide this infrastructure as a
public API. If I have a class of mine and want to provide convenience for
connecting to slots/callables, how do I do it without using private APIs? In
Qt 4 days that was a simple:

 void foo(..., QObject *receiver, const char *slot);

But it's not so simple/possible any more with the PMF syntax.

Something like

   void foo(...,
        QObject *guard,
    const std::function<void(const Result &)> &continuation)

does a sufficiently good job over here.


That helps with specific cases, but for the general-purpose library APIs that have the flexibility we are used to in and from Qt, you need to cover when

- continuation is a member function of guard (and then guard has to be the right type, which should be enforced at compile time)
- guard lives in a different thread
- guard is destroyed by the time you call continuation

And you have to make things work with move-only functors and mutable lambdas.

Getting all of that right was never particularly easy with a string-based syntax either though.

Volker



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230504/410907e4/attachment-0001.htm>