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 <[email protected]>: > 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 <[email protected]> > *Sent:* Saturday, May 8, 2021 2:29 AM > *To:* Arno Rehn <[email protected]> > *Cc:* Sona Kurazyan <[email protected]>; Qt development mailing list < > [email protected]> > *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 <[email protected]>: > > 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 > [email protected] > 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 > [email protected] > https://lists.qt-project.org/listinfo/development > >
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
