On 3 May 2023, at 19:32, A. Pönitz <apoen...@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
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
