[Development] QMetaType support for QFuture

[Konstantin Ritt]

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>:

> 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>
> *Sent:* Saturday, May 8, 2021 2:29 AM
> *To:* Arno Rehn <a.rehn at menlosystems.com>
> *Cc:* Sona Kurazyan <sona.kurazyan at qt.io>; Qt development mailing list <
> 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>:
>
> 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
> 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
> https://lists.qt-project.org/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210508/7034afb2/attachment.html>