Bot releases are hidden (Show)
Full Changelog: https://github.com/danvratil/qcoro/compare/v0.9.0...v0.10.0
Published by danvratil over 1 year ago
Full Changelog: https://github.com/danvratil/qcoro/compare/v0.8.0...v0.9.0
Published by danvratil over 1 year ago
Full Changelog: https://github.com/danvratil/qcoro/compare/v0.7.0...v0.8.0
Published by danvratil almost 2 years ago
Full Changelog: https://github.com/danvratil/qcoro/compare/v0.6.0...v0.7.0
Published by danvratil over 2 years ago
Full Changelog: https://github.com/danvratil/qcoro/compare/v0.5.1...v0.6.0
Published by danvratil over 2 years ago
Published by danvratil over 2 years ago
.then()
continuation for Task<T>
(#39)QCoro::waitFor()
getting stuck when coroutine returns synchronously (#46)Task<T>
from all operations (#54)QThread
(commit 832d931)Published by danvratil almost 3 years ago
Published by danvratil about 3 years ago
Published by danvratil about 3 years ago
QCoro 0.2.0 contains brings major reorganization of the code. While there are no API-incompatible changes, users updating
from 0.1.0 will have to adjust #include
statements for QCoro headers in their projects.
The code has been reorganized into three modules (and thus three standalone libraries): QCoroCore, QCoroDBus and
QCoroNetwork. QCoroCore contains the elementary QCoro tools (QCoro::Task
, qCoro()
wrapper etc.) and coroutine
support for some QtCore types. The QCoroDBus module contains coroutine support for types from the QtDBus module
and equally the QCoroNetwork module contains coroutine support for types from the QtNetwork module. The latter two
modules are also optional, the library can be built without them. It also means that an application that only uses
let's say QtNetwork and has no DBus dependency will no longer get QtDBus pulled in through QCoro, as long as it
only links against libQCoroCore
and libQCoroNetwork
. The reorganization will also allow for future
support of additional Qt modules.
The include headers in QCoro we a bit of a mess and in 0.2.0 they all got a unified form. All public header files
now start with qcoro
(e.g. qcorotimer.h
, qcoronetworkreply.h
etc.), and QCoro also provides CamelCase headers
now. Thus users should simply do #include <QCoroTimer>
if they want coroutine support for QTimer
.
The reorganization of headers makes QCoro 0.2.0 incompatible with previous versions and any users of QCoro will
have to update their #include
statements. I'm sorry about this extra hassle, but with this brings much needed
sanity into the header organization and naming scheme.
The documentation has been updated to reflect the reorganization as well as some internal changes. It should be
easier to understand now and hopefully will make it easier for users to start with QCoro now.
Historically, certain types types which can be directly co_await
ed with QCoro, for instance QTimer
has their
coroutine support implemented differently than types that have multiple asynchronous operations and thus have
a coroutine-friendly wrapper classes (like QIODevice
and it's QCoroIODevice
wrapper). In 0.2.0 I have unified
the code so that even the coroutine support for simple types like QTimer
are implemented through wrapper classes
(so there's QCoroTimer
now)
Published by danvratil about 3 years ago
Initial release of QCoro.