[Development] QMetaType support for QFuture

[Fabian Kosmale]

Regarding the API:
I think the most common pattern in Qt would be to add a static get method to the private class.

@Arno: But would that accessor actually be enough for you? As in, do you know in your case that the QVariant contains a QFuture? If you get a generic QVariant instead, you may still need a way to detect that the contained type is in fact a QFuture (though QMetaType::name might be enough in that case).

--
Fabian Kosmale
Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosmale at qt.io
+49 1638686070
http://qt.io


Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

--

________________________________________
Von: Development <development-bounces at qt-project.org> im Auftrag von Sona Kurazyan <sona.kurazyan at qt.io>
Gesendet: Montag, 10. Mai 2021 09:55
An: Konstantin Ritt
Cc: Qt development mailing list
Betreff: Re: [Development] QMetaType support for QFuture

I was suggesting QtPrivate::, since QFutureInterface/QFutureInterfaceBase aren’t public and access to QFuture’s d-ptr is not something we would want to recommend generally, I don’t think the average user will need it.
But, of course, the exact API can be discussed.

Best regards,
Sona

From: Konstantin Ritt <ritt.ks at gmail.com>
Sent: Saturday, May 8, 2021 6:26 PM
To: Sona Kurazyan <sona.kurazyan at qt.io>
Cc: Arno Rehn <a.rehn at menlosystems.com>; Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] QMetaType support for QFuture

Can't we simply `QFutureInterface(const QFuture<T> &future)` to get that future's QFutureInterface, w/o any QtPrivate:: ugliness?


Regards,
Konstantin


сб, 8 мая 2021 г. в 11:30, Sona Kurazyan <sona.kurazyan at qt.io<mailto:sona.kurazyan at qt.io>>:
Hi Konstantin,

QFuture has a constructor for QFuture<void> from QFuture<T>,  see https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/thread/qfuture.h#n82, so you don’t even need to use the broken qToVoidFuture() method. I’ll probably remove it, since it was always broken and couldn’t be ever used.
I can see that in some special use-cases having access to QFuture’s internals might be useful, but this is not something we would recommend to do to all users. That’s why, I think, adding an API that gives access to QFuture’s d-ptr (as it was suggested earlier) might be an option.

Best regards,
Sona

From: Konstantin Ritt <ritt.ks at gmail.com<mailto:ritt.ks at gmail.com>>
Sent: Saturday, May 8, 2021 2:29 AM
To: Arno Rehn <a.rehn at menlosystems.com<mailto:a.rehn at menlosystems.com>>
Cc: Sona Kurazyan <sona.kurazyan at qt.io<mailto:sona.kurazyan at qt.io>>; Qt development mailing list <development at qt-project.org<mailto:development at qt-project.org>>
Subject: Re: [Development] QMetaType support for QFuture

I was implementing a similar feature few years ago and had the same problem with QFuture internals -- https://codereview.qt-project.org/c/qt/qtbase/+/210243
As there was no interest in making those better, I had to hack it in a way I won't promote here ;p
But since QFuture took a new life with QPromise, it becomes even more useful than before and deserves some improvements IMO.
Maybe we could add a public accessor to future's d via QFutureInterfaceBase? Will that be acceptable?

Regards,
Konstantin


пт, 7 мая 2021 г. в 19:28, Arno Rehn <a.rehn at menlosystems.com<mailto:a.rehn at menlosystems.com>>:
Hi Sona,

On 07.05.21 17:11, Sona Kurazyan wrote:
> You could use the QFutureInterfaceBase (non-templated) class directly
> to build a type-erased future, that's basically what QFuture is using
> underneath. Although it's internal (not documented and is considered
> to be private), but it's declared in a public header
> (qfutureinterface.h) and you can still use it. QFutureInterfaceBase's
> methods for accessing its internals are public (with a few exceptions
> that you probably won't need to use). I hope that helps.

Yep, that's what I thought as well. But I cannot get it from an existing
QFuture because it's a private member. We could add some private API to
extract the QFutureInterfaceBase, however.

Anyway, I think I'll have to add some QMetaType magic anyway for this to
work. In QtWebChannel, we get the method return value wrapped in a
QVariant, so the QFuture<T> is wrapped in a QVariant. From there, I
cannot extract the QFutureInterfaceBase in any way.

I *could* just memcpy from QVariant's data pointer to a
QFutureInterfaceBase*, but I'm pretty sure that this is UB.

Any pointer where to start?

Regards,
Arno

--
Arno Rehn
Tel +49 89 189 166 0
Fax +49 89 189 166 111
a.rehn at menlosystems.com<mailto:a.rehn at menlosystems.com>
www.menlosystems.com<http://www.menlosystems.com>

Menlo Systems GmbH
Bunsenstrasse 5, D-82152 Martinsried, Germany
Amtsgericht München HRB 138145
Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
USt.-IdNr. DE217772017, St.-Nr. 14316170324
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development