Move porting guide for QtConcurrent to its designated page
Also move the porting section for QFuture and related classes after the section for view classes, to make the order more natural for reading. Change-Id: I5ea816d7bb3dfdda2b74112418bf07954c9ec94c Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>bb10
Sona Kurazyan
parent
0526ae3f03
commit
e53a3bd85a
|
|
@ -41,6 +41,36 @@
|
|||
In this topic we summarize those changes in Qt Concurrent, and provide
|
||||
guidance to handle them.
|
||||
|
||||
\section1 ADD STUFF HERE
|
||||
\section1 QtConcurrent::run()
|
||||
|
||||
QtConcurrent::run() has been improved to work with a variable number
|
||||
of arguments, so the signatures are changed to:
|
||||
|
||||
\code
|
||||
// run
|
||||
template <typename T>
|
||||
QFuture<T> run(Function &&f, Args &&...args)
|
||||
|
||||
// run with a QThreadPool argument
|
||||
template <typename T>
|
||||
QFuture<T> run(QThreadPool *pool, Function &&f, Args &&...args)
|
||||
\endcode
|
||||
|
||||
As a side effect, if \c f is a pointer to a member function, the first
|
||||
argument of \c args should be the object for which that member is defined
|
||||
(or a reference, or a pointer to it). So instead of writing:
|
||||
|
||||
\code
|
||||
QImage image = ...;
|
||||
QFuture<void> future = QtConcurrent::run(&image, &QImage::invertPixels, QImage::InvertRgba);
|
||||
\endcode
|
||||
|
||||
You have to write:
|
||||
|
||||
\code
|
||||
QFuture<void> future = QtConcurrent::run(&QImage::invertPixels, &image, QImage::InvertRgba);
|
||||
\endcode
|
||||
|
||||
Other methods of QtConcurrent have no behavioral changes and do not introduce
|
||||
source compatibility breaks.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -176,77 +176,6 @@
|
|||
to cases where QVector or QList with a non C-compatible array layout were
|
||||
used originally.
|
||||
|
||||
\section1 QtConcurrent and Related Classes
|
||||
|
||||
\section2 QFuture and QFutureWatcher
|
||||
|
||||
In Qt 6, there are no changes that introduce source compatibility breaks
|
||||
in code that was using QFuture and QFutureWatcher classes. However there
|
||||
were some improvements which caused the following behavioral changes:
|
||||
|
||||
\list
|
||||
|
||||
\li After pausing QFuture or QFutureWatcher (by calling \c pause() or
|
||||
\c setPaused(true)), QFutureWatcher will not immediately stop delivering
|
||||
progress and result ready signals. At the moment of pausing there may be
|
||||
still computations that are in progress and cannot be stopped. Signals
|
||||
for such computations may be still delivered after pause, instead of being
|
||||
postponed and reported only after next resume. To get notified when pause
|
||||
actually took effect, QFutureWatcher::suspended() signal can be used. In
|
||||
addition, there are new \c isSuspending() and \c isSuspended() methods,
|
||||
to check if the QFuture is in the process of suspending or it's already in
|
||||
the suspended state. Note that for consistency reasons, for both QFuture
|
||||
and QFutureWatcher the pause-related APIs were deprecated and replaced by
|
||||
similar methods having "suspend" in the name instead.
|
||||
|
||||
\li QFuture::waitForFinished() will now wait until QFuture is actually in
|
||||
the finished state, instead of exiting as soon as it is not in the running
|
||||
state. This prevents \c waitForFinished() from exiting immediately, if at
|
||||
the moment of calling it the future is not started yet. The same applies to
|
||||
QFutureWatcher::waitForFinished(). This change won't affect the behavior of
|
||||
code that was using QFuture with QtConcurrent. Only the code that was using
|
||||
it with the undocumented \c QFutureInterface may be affected.
|
||||
|
||||
\endlist
|
||||
|
||||
\section2 QPromise
|
||||
|
||||
In Qt 6, the new QPromise class should be used instead of unofficial
|
||||
QFutureInterface as a "setter" counterpart of QFuture.
|
||||
|
||||
\section2 QtConcurrent::run()
|
||||
|
||||
QtConcurrent::run() has been improved to work with a variable number
|
||||
of arguments, so the signatures are changed to:
|
||||
|
||||
\code
|
||||
// run
|
||||
template <typename T>
|
||||
QFuture<T> run(Function &&f, Args &&...args)
|
||||
|
||||
// run with a QThreadPool argument
|
||||
template <typename T>
|
||||
QFuture<T> run(QThreadPool *pool, Function &&f, Args &&...args)
|
||||
\endcode
|
||||
|
||||
As a side effect, if \c f is a pointer to a member function, the first
|
||||
argument of \c args should be the object for which that member is defined
|
||||
(or a reference, or a pointer to it). So instead of writing:
|
||||
|
||||
\code
|
||||
QImage image = ...;
|
||||
QFuture<void> future = QtConcurrent::run(&image, &QImage::invertPixels, QImage::InvertRgba);
|
||||
\endcode
|
||||
|
||||
You have to write:
|
||||
|
||||
\code
|
||||
QFuture<void> future = QtConcurrent::run(&QImage::invertPixels, &image, QImage::InvertRgba);
|
||||
\endcode
|
||||
|
||||
Other methods of QtConcurrent have no behavioral changes and do not introduce
|
||||
source compatibility breaks.
|
||||
|
||||
\section1 View classes in Qt6
|
||||
|
||||
\section2 General Overview
|
||||
|
|
@ -464,6 +393,44 @@
|
|||
}
|
||||
\endcode
|
||||
|
||||
\section1 QFuture and Related Classes
|
||||
|
||||
\section2 QFuture and QFutureWatcher
|
||||
|
||||
In Qt 6, there are no changes that introduce source compatibility breaks
|
||||
in code that was using QFuture and QFutureWatcher classes. However there
|
||||
were some improvements which caused the following behavioral changes:
|
||||
|
||||
\list
|
||||
|
||||
\li After pausing QFuture or QFutureWatcher (by calling \c pause() or
|
||||
\c setPaused(true)), QFutureWatcher will not immediately stop delivering
|
||||
progress and result ready signals. At the moment of pausing there may be
|
||||
still computations that are in progress and cannot be stopped. Signals
|
||||
for such computations may be still delivered after pause, instead of being
|
||||
postponed and reported only after next resume. To get notified when pause
|
||||
actually took effect, QFutureWatcher::suspended() signal can be used. In
|
||||
addition, there are new \c isSuspending() and \c isSuspended() methods,
|
||||
to check if the QFuture is in the process of suspending or it's already in
|
||||
the suspended state. Note that for consistency reasons, for both QFuture
|
||||
and QFutureWatcher the pause-related APIs were deprecated and replaced by
|
||||
similar methods having "suspend" in the name instead.
|
||||
|
||||
\li QFuture::waitForFinished() will now wait until QFuture is actually in
|
||||
the finished state, instead of exiting as soon as it is not in the running
|
||||
state. This prevents \c waitForFinished() from exiting immediately, if at
|
||||
the moment of calling it the future is not started yet. The same applies to
|
||||
QFutureWatcher::waitForFinished(). This change won't affect the behavior of
|
||||
code that was using QFuture with QtConcurrent. Only the code that was using
|
||||
it with the undocumented \c QFutureInterface may be affected.
|
||||
|
||||
\endlist
|
||||
|
||||
\section2 QPromise
|
||||
|
||||
In Qt 6, the new QPromise class should be used instead of unofficial
|
||||
QFutureInterface as a "setter" counterpart of QFuture.
|
||||
|
||||
\section1 IO Classes
|
||||
|
||||
\section2 QProcess
|
||||
|
|
|
|||
Loading…
Reference in New Issue